On Mon, 2009-04-27 at 11:55 -0400, Dan Winship wrote: > Ryan Lortie wrote: > > Not sure I agree. See shutdown() syscall. The fact that this call > > exists means that the designers of [unix or tcp or whatever] went out of > > their way because they disagreed with you. > > I can't think of any time I've used SHUT_RD or SHUT_WR rather than > SHUT_RDWR though...
You can use SHUT_WR to get reliable socket shutdown, making sure the remote side got all the data (without using SO_LINGER). See e.g.: http://blog.netherlabs.nl/articles/2009/01/18/the-ultimate-so_linger-page-or-why-is-my-tcp-not-reliable Although this kind of thing looks like something the highlevel code should support not by exposing shutdown, but rather by having a function that does all of this. > >> Furthermore, its actually a problem in the ipv4 vs ipv6 magic case. The > >> current tcplistener code first tries to do an ipv6 socket and only if > >> that fails it tries an ipv4 socket. This makes sense on linux, were an > >> ipv6 socket also can accept ipv4 connections. However, this is not true > >> on many other unixes, where you need two sockets to handle both ipv4 and > >> ipv6. So in this case the listener object actually gets in the way, as > >> we'd need to create two listener objects to handle this (or make the > >> listener have two sockets). > > > > The 4-over-6 functionality (and even the setsockopt to disable it) is > > specified in some RFC somewhere. > > Right, but it's disabled (at the kernel level) by default on most OSes > (everything but Linux?) because apparently the behavior is > underspecified. (Eg, see > http://www.potaroo.net/ietf/idref/draft-cmetz-v6ops-v4mapped-api-harmful/.) > > So to avoid separate Linux-vs-everyone-else codepaths, it's probably > best to use IPV6_V6ONLY and manage v4 and v6 sockets separately everywhere. As per http://people.redhat.com/drepper/userapi-ipv6.html this doesn't work for linux, as it only allows one socket per port. Isn't portable programming fun! _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list