From: Reinhard M. <ma...@tc...> - 2012-08-23 14:09:03
|
On Thu, 23 Aug 2012 at 15:32, Trevor Davel (Twylite) wrote: > The echo server snippet I gave is a good example: > > proc echo_callback {dgramCmd payload remote meta} { > puts "Datagram from [$dgramCmd endpointToStr $remote]: $payload" > $dgramCmd send "ECHO: $payload" $remote > } > > This server is given the dgramCmd corresponding to the local socket, > and is given the sender's endpoint ($remote). It can then process > the datagram and respond without knowing anything about the protocol > or how to identify an endpoint for that protocol. Yes! Such an endpoint descriptor could either be a protocol speciffic list ({host port} for UDP, maybe something like {VendorID DeviceID configuration interface endpoint} for USB), or (IMO better) a dict that is not only suitable for replying through the same [dgram] instance through which the initiating datagram was received, but also to create a new [dgram] that is suitable for communicating with that remote endpoint. > Not the same thing -- -remoteaddr connects the socket, so you can't > send to or receive from other remote addresses. According to the connect() manpag (I haven't tried it out yet), it limits reception to that address and sets it as the default for sending, but sending to other destinations is still possible. > I'm thinking of the situation where you have a list of hostnames > that you will send to regularly, and don't want to resolve the name > on every [$d send]. The problem I see with this is that the standard name resolution functions don't provide the TTL of DNS entries, so you don't know for how long you are allowed to cache the addresses and I hate applications that that cache IP addresses way beyond their TTL, especially for short-lived things like dyndns. cu Reinhard |