Re: [Libevent-users] Libevent, DBus, Netlink, peeking at packet lengths, etc.

[Azat Khuzhin <a3at.mail@xxxxxxxxx>]

On Tue, Aug 16, 2016 at 01:42:35PM -0600, Philip Prindeville wrote:
> Hi,

Hi Philip,

> Is there a preferred way of supporting Netlink or DBus traffic? I ask
> because I'm thinking of a long-running daemon on a laptop that might need to
> get notifications about roaming onto different network types via Netlink,
> for instance.  I did see this library out there but wasn't sure how complete
> and tested it was:
> 
> https://github.com/dex/dbus-service

There is no official support for DBus, though DBus exports regular
socket's so you can always wrap them (like in that project at github).

And also ther is no official support for netlink, but you can try wrap
them of course (using libnl for instance).

> 
> Also, in the case of handling a protocol with fixed-size records (like
> Tacacs+) running over TCP, is there a preferred way to read a
> packet-at-a-time?  Since it's TCP, you have no record boundaries (unlike UDP
> or TP-4), so you have to find the packet length inside the header.
> 
> In my case, in my read callback, I'm doing this as:
> 
>       evbuf = bufferevent_get_input(bev);
> 
>       n = evbuffer_get_length(evbuf);
> 
>       /* evbuffer_pullup() returns NULL if there aren't enough bytes in
>        * the buffer yet to pull-up as many as are requested.
>        */
>       start = evbuffer_pullup(evbuf, TAC_PLUS_HDR_SIZE);
>       if (! start)
>           return;
> 
>       th = (HDR *)start;
> 
>       /* should probably bcopy th->datalength to a word-aligned buffer
>        * first, in case we're on a platform which doesn't handle word
>        * fetches on unaligned addresses
>        */
> 
>       length = ntohl(th->datalength) + TAC_PLUS_HDR_SIZE;
> 
>       /* if we're short, we'll get called again when more data arrives
>        */
>       if (n < length)
>            return;
> 
>       u_char *pkt = malloc(length);
> 
>       /* copy out... */
>       i = evbuffer_remove(evbuf, pkt, length);
> 
>       tac_parse_pkt(ctx->sess, ctx, pkt, length);
> 
>       free(pkt);
> }
> 
> But wondered if there's a better or prototypical way of handling this?

Probably you can use bufferevent_filter_new() (you take a look at [1] for
example).

But be aware of [2], I don't think that you version of libevent doesn't
suffer from this problem.

> Is it worth setting the socket low-water market to "length" so that we only
> get dispatched one more time if data trickles in?

In this case libevent will not call your callback if evbuffer doesn't
have enough data, so you can use this, instead of first if for length in
your cb.

> Also, is there any interest in adding 'profiling' support to the event
> handlers to see how long they run (in real-time, probably using
> gettimeofday()) and generating warnings in debug- (or development-) mode if
> they exceed an upper threshold (say 10ms execution time)?

You can add it, since libevent doesn't have it, though it do have
event_enable_debug_logging() and you can add timestamps there.

[1]: https://github.com/libevent/libevent/blob/master/test/regress_zlib.c
[2]: https://github.com/libevent/libevent/commit/b627ad88

  Azat.
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.