Adrian Chadd <adr...@creative.net.au> wrote Wed, 12 Dec 2012 20:59:36 -0800:
| ... why would you want to use bufferevent for this? I think it would be useful for programs implementing protocols using both stream- and packet-oriented networks to have a common abstraction. Examples include DNS, SIP and RADIUS. And perhaps also some audio and video codecs? | You really want something like bufferevent, except: | | * You want to attach source/destination IP:port info, as an option; | * You want to support scatter/gather IO as an option; | * You want to be able to have well defined boundaries - ie, "This is a | datagram in its entirety" versus "let's incrementally fill this buffer | bufferevent style." | | So I think something almost-but-not-quite like bufferevent is needed. For writing to a datagram socket, would it make sense to treat the write high-water mark (currently used only for filters and pairs) to decide when to send a datagram? Applications could treat the transport as a stream and ask the bufferevent to chop it up in chunks of a fixed size. That would be in addition to bufferevent_flush() sending what's currently in the output buffer, for a more record-oriented view of the data. For reading, it might be neat to be able to have your program say "let me know when you have N packets of data", i.e. having a read low-water mark expressing number of packets received rather than number of octets read. Not sure it'd be worth any complexity in the library though. _______________________________________________ Libevent-users mailing list Libevent-users@monkey.org http://lists.monkey.org:8080/listinfo/libevent-users
