Re: [Libevent-users] Re: IOCP writes
William Ahern wrote: I admittedly don't no anything about IOCP. What I do no is that it doesn't make sense to use any other function call then send() or sendto() to write out UDP data. So whatever API your writing around IOCP, it should short-circuit for UDP writes; just call send() to sendto(). But, that's all I'll say for now, since eventually I'm just going to look foolish for my lack of IOCP knowledge. Well, I think here in lack of knowledge has led you to point out something that I simply hadn't thought of because I've been thinking about everything in terms of IOCP. ___ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
Re: [Libevent-users] Re: IOCP writes
On Thu, Feb 22, 2007 at 09:01:00PM +, Toby Douglass wrote: > However, I've just realized that it may make no difference. > > Writing to a UDP socket should never block; agreed. > > However, that multiple concurrent writes (one socket, many writer > threads) can occur, and so the internal mechanics of the IOCP API must > support that behaviour (assume we have enough bandwidth and the write > rate is low enough that we're not dropping packets). > > If I only have a single overlapped structure for writes, I cannot > support that behaviour. > > So I have to malloc the overlapped structure per write (or have the user > pass one in). I admittedly don't no anything about IOCP. What I do no is that it doesn't make sense to use any other function call then send() or sendto() to write out UDP data. So whatever API your writing around IOCP, it should short-circuit for UDP writes; just call send() to sendto(). But, that's all I'll say for now, since eventually I'm just going to look foolish for my lack of IOCP knowledge. ___ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
Re: [Libevent-users] Re: IOCP writes
On Thu, Feb 22, 2007 at 08:26:22PM +, Toby Douglass wrote: > >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. > > So, the final implication is that users will ONLY ever perform serial > writes on a socket, no matter what it is? I'm not following. What I was trying to say is that I suspect the NIC will push packets onto the network faster than the network can handle. Meaning, trying not to overflow the local buffer doesn't buy you anything. Example: If the NIC is on a 100BaseT, but the gateway is on a T3, even if you didn't overflow the UDP stack locally, you'd still get tons of packet loss at the gateway, because it couldn't possibly forward them all onto the T3. In other words, trying to limit your send rate by using the local buffer as a throttle doesn't make sense; the local buffer is almost never the bottleneck, unless you've still got a USR Sportster on a serial cable ;) So, at the end of the day, to send UDP packets all you need to do is call send() or sendto(). No IOCP, no polling, no nothing. Everything goes out as discrete units, so you don't need anything worry about concurrent thread access or anything like that, either. You're socket writes will never get interleaved, since that's simply not the way UDP works at any level (protocol, implementation, or API). ___ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
Re: [Libevent-users] Re: IOCP writes
Toby Douglass wrote: William Ahern wrote: On Thu, Feb 22, 2007 at 01:43:48PM -, Toby Douglass wrote: 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. Good point. I'd forgotten about that. However, I've just realized that it may make no difference. Writing to a UDP socket should never block; agreed. However, that multiple concurrent writes (one socket, many writer threads) can occur, and so the internal mechanics of the IOCP API must support that behaviour (assume we have enough bandwidth and the write rate is low enough that we're not dropping packets). If I only have a single overlapped structure for writes, I cannot support that behaviour. So I have to malloc the overlapped structure per write (or have the user pass one in). ___ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
Re: [Libevent-users] Re: IOCP writes
William Ahern wrote: On Thu, Feb 22, 2007 at 01:43:48PM -, Toby Douglass wrote: 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. Good point. I'd forgotten about that. But, that could just as well have happened on the wire, so what's the difference? It would be more reliable not to fail locally if you could avoid it. The fact it *could* happen on the wire doesn't give us license to drop things when we could have avoided it. 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. So, the final implication is that users will ONLY ever perform serial writes on a socket, no matter what it is? ___ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
Re: [Libevent-users] Re: IOCP writes
On Thu, Feb 22, 2007 at 01:43:48PM -, 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
Re: [Libevent-users] Re: IOCP writes
On Thu, Feb 22, 2007 at 12:09:18AM +0100, Rhythmic Fistman wrote: > Issuing simultaneous asynchronous reads and writes on socket is a tiny bit > rare and special. Are you sure that's what you want to do? If so, great - > io completion queues can handle it. Bu-ut if libevent was modelled on the > unix > select-style interfaces, most of which don't easily support this kind of > thing, > how is this situation cropping up, assuming that this is just an IOCP port > of libevent? Almost all of my use of libevent involves simultaneous reads/writes, for relays which filter streams on-the-fly, in both directions. It was tricky at first, but over the course of several revisions it all settled out. *sigh* Someday I'll have to muster up the energy to change the name, because on this list its just damn confusing, but my buffered-IO implementation is in libevnet: http://www.25thandclement.com/~william/projects/libevnet.html Specifically, see src/bufio/socket.c and the functions bufio_socket_event_run bufio_socket_event_mod bufio_socket_event_del bufio_socket_event_add bufio_socket_poll_handler bufio_sink_poll_handler Cancellations were tricky. Also, what I fail to see in most async libraries is logic to handle re-entrancy from recursive callbacks. That's what the FRAME_PUSH/FRAME_POP calls are all about. evdns.c fails in this respect, last time I looked, as does c-ares; they'll just segfault. My lookup API, built around c-ares, works around the c-ares problem w/ what I consider an abysmal hack; I'm looking to maybe fork the guts into libevnet because my re-entrancy patches were rejected. Anyhow, lookup.c does much, much more than c-ares, ADNS, or evdns, combined. ___ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
