Re: [Libevent-users] Libevent2 - Support for UDP in bufferevent

[Etienne Samson <samson.etienne@xxxxxxxxx>]

Hi !

I'm the UDP guy Nick just mentioned ;-)

I just happen have an old in-progress email that discusses the details of what I was attempting w.r.t. UDP, so I guess it's the good time to discuss this.

My work is at [1] below. Be aware that this haven't been updated (yes, the merge isn't easy ;-)). I'm planning to update it sometime but since the release cycle is currently locked and it has a rather low priority, it's blocked atm.

The main issue I had with using UDP in libevent is that (IIRC) you're forced to put your socket in connected state, because evbuffer access the fd using read() and write().

My plan was :
- to abstract those calls in their own functions (evsocket_read, evsocket_write), along with all the other possible means currently available (see [2] for the list I had in my branch). This also cleans up 
- allow the library client to choose whatever implementation it wanted (via evbuffer_set_fd_cbs [2]), while defaulting to the best implementation for the descriptor (connected/disconnected, iovecs supported on platform, in that order, see the switch in evbuffer_read()/write() and evsocket_type()).
- allow those callbacks to gather/use whatever data they want when the fd gets activity via evsocket_info (right now that limited to the sockaddr to send to when writing, and the sockaddr that sent us data when reading, but I guess it could also handle OOB data)...

Issues: 
- sendfile support is out of the window, mainly because it's a special cased evbuffer. Its implementation has been moved in evsocket_sendfile, and IIRC the call should go in evbuffer_write_atmost.
- crashes galore !

[1] - http://github.com/tiennou/Libevent/tree/evbuffer_fd_cbs
[2] - http://github.com/tiennou/Libevent/blob/evbuffer_fd_cbs/include/event2/evsocket.h

Le 1 déc. 2010 à 16:44, Nick Mathewson a écrit :

> On Wed, Dec 1, 2010 at 8:22 AM, Thai Duong <thaidn@xxxxxxxxx> wrote:
>> Hi everybody,
>> 
>> I'm new to this list, so please forgive me if this has been discussed.
>> I read the libevent2 book, and it said that bufferevent currently
>> supports only TCP socket. I take a look at the code, and see that,
>> however, it seems that bufferevent can work with UDP too.
> 
> The evbuffer backend that bufferevents uses to store incoming and
> outgoing data currently assumes that it's handling stream data rather
> than datagrams, and as such does not preserve packet boundaries when
> reading and writing.

I'm not sure about this too (in fact, I hadn't though about it...). IIRC my plan was to exchange only packet-sized buffers, with a small header at the start...

> There are probably other issues as well, but that one's enough of a
> showstopper to make bufferevents+UDP unworkable in the current code
> base.
> 
>> So my
>> question is why the book said that UDP is not supported?
> 
> Because it's the truth.
> 
>> And if that
>> is really the case, what should I do to modify bufferevent so that it
>> supports UDP?
> 
> It will probably take a fair amount of programming.  You'd want to
> start by thinking about the appropriate abstractions at the evbuffer
> level, and then considering which abstractions are appropriate for
> making evbuffers work on packets rather than streams without making
> either implementation inefficient or making either API ugly or hard to
> use.  At the same time, you'd want to have a look through the
> bufferevent code and see what stream-only assumptions (if any) it
> makes, and what would need to be done to fix those.
> 
> Etienne Samson was working on a design for this a while back, and I'd
> like to revisit it for Libevent 2.1.  You can have a look at the state
> of his work here:
> https://sourceforge.net/tracker/?func=detail&aid=2928202&group_id=50884&atid=461324
> .  It makes some choices that I didn't agree with at the time, though
> to be honest I haven't looked at it recently and can't currently
> remember which they were.
> 
> This is also probably a good time to apologize to Etienne for being so
> slow here; the Libevent 2.0 release cycle has been entirely too long.
> Once 2.0.x-stable is out, it's probably a good idea to consider ways
> to make sure that 2.1 does not spend so long in alpha as 2.0.x did.

Apologies taken ;-). In fact, I was just playing around with libevent when I found out that it didn't like UDP sockets, so that not like I was in a hurry...

> 
> yrs,
> -- 
> Nick


--
Etienne Samson
samson.etienne@xxxxxxxxx***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.