On Thu, Feb 22, 2007 at 01:43:48PM -0000, Toby Douglass wrote: > > From: "Toby Douglass" <[EMAIL PROTECTED]> > >> As it is, it's easy to support serial writes with IOCP, it's supporting > >> multiple concurrent writes which is awkward for a convenient-to-use API > >> over IOCP - and this I would think is absolutely required for some uses > >> of UDP sockets. > > > I haven't tried any UDP async socket stuff, not with IOCPs nor anything. > > Tell us how it goes! > > Well, it's something I've rarely needed to do - in fact, only for P2P VOIP. > > However, the example I had in mind (which is similar) is P2P apps, which > use writes on a single local UDP socket to send peering information to > peers. They would benefit from async writes on that socket.
Writing to a UDP socket should never block, period. If the output buffer is full, and you write another message, it should force the stack to drop a message. But, that could just as well have happened on the wire, so what's the difference? Likely what the NIC can push out and what the link can handle is different, so trying to cater to the output buffer is a futile excercise, as far as I can see. > > Still, I think I'm missing the point of multiple > > concurrent writes - wouldn't the output be undefined? > > Ah, no, because the destination on a UDP socket will be specified for each > write. For a TCP socket, your concern is correct, multiple async writes > would only be useful if each write was independent of every other write, > so the ordering of dispatch didn't matter. (We would also need to assume > each send() function call wrote its payload atomically with regard to > other send() function calls, which I think is true, although I don't know > that it is actually guaranteed). It is guaranteed. You may get truncation or fragmentation, but a UDP fragment is still a logical, discrete unit. _______________________________________________ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
