Date: Mon, 26 Mar 2001 16:02:23 -0800 From: "Jonathan Graehl" <jonathan@graehl.org> To: "Bill Fenner" <fenner@research.att.com> Cc: "Freebsd-Net" <freebsd-net@freebsd.org> Subject: RE: proper way to test for INET/INET6? Message-ID: <NCBBLOALCKKINBNNEDDLGECODNAA.jonathan@graehl.org> In-Reply-To: <200103262209.OAA14300@windsor.research.att.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > Don't you receive the 2nd packet on the connected socket? > Suppose I've bound UDP serv_ip/serv_port (unconnected). I loop receiving a datagram from client_ip/client_port. I look for an entry in my hash table for client_ip/client_port. If there is one, it points to a connected UDP socket from */* to dest_ip/dest_port (the proxied destination), and I forward the datagram there. If there is no such entry, I create one, and a new connected UDP socket for that client. I also read from that socket and Every once in a while I remove inactive client entries (both their connected socket to the destination, and the entry in the hash table). I do indeed receive replies from the proxied dest_ip/dest_port on individual connected sockets. However, even with SO_REUSEADDR and SO_REUSEPORT, there is no sensible way for me to create connected sockets for each client_ip/client_port->serv_ip/serv_port and be assured that matching messages do indeed go to that socket, rather than the more general service port. The hash table is to distinguish new clients from old, since all packets destined to serv_ip/serv_port must come through my one socket. Ideally I could bind/listen/accept UDP sockets to end up with one connected socket per client. The fact that a bind() queues up messages could be a problem, and in fact, there are situations where an unambiguous (more specific than the existing) TCP listen or connect cannot be made even with SO_REUSEADDR, because binding the local endpoint is done first, rather than atomically assigning both the local and remote endpoint while connecting or listening. Other servers have gotten around the inability to "listen" for UDP connected sockets by having the server connect() back to the client from a different port; however, this is less than transparent as far as NAT is concerned. -- Jonathan Graehl http://jonathan.graehl.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?NCBBLOALCKKINBNNEDDLGECODNAA.jonathan>