abstracting pcap_loop with futures::Stream

[Roxxik]

is there any way to get a stream of packets? if not i'd be highly interested in building this functionality on top of this crate. I think this is achievable by using mpsc channels within the handler of pcap_loop i'm not yet sure how to get pcap_breakloop into the picture.

I want to use this within a small tool i'm currently building and async packet handling would be a blessing

[aldanor]

Do you mean non-blocking / async? I think it should be fairly straightforward using mpsc sync, although... note the lifetime on Packet, it's currently reusing the same memory for all packets to avoid allocations -- I don't know if that will be a problem.

[ebfull]

I recall there being an async (callback-based) packet notification API in pcap, which would work nicely with futures, but I don't remember what platform support looks like.

[Roxxik]

pcap_loop is callbck based, but blocking. I'd tend to use pcap_get_selectable_fd and pcap_set_nonblocking so that it can be handled within a single thread and then throwing an unsync::mpsc ontop to provide the stream

[Roxxik]

If someone wants to watch: here is a compiling, but yet untested version of it: https://github.com/Roxxik/pcap (it's not yet polished and might need some refactoring)

EDIT: i would like to publish that in it's own crate, because it draws quite some dependencies and is not really dependant on any other part of this lib. All i would need is a get_selectable_fd and set_noblock function. then this can be moved to a pcap-tokio package (or similar)

[vorner]

I would be interested in having tokio-integrated pcap, too.

@Roxxik: What are your plans with your branch? How would you feel if I extracted the changes for this branch (eg. get_selectable_fd, …) and created a pull request, as a first step to some tokio-pcap crate?

[Roxxik]

@vorner I don't have that much time currently. Just go ahead and if i have some spare time, i'm picking up the changes. my plan was to build a very simple tui application on top of a stream of packets. I have started some minimal printing of the stream, aggregated packet and byte count, and maybe the average packet size, but that's it. I'm not sure whether that code is on github yet. If not i can upload it later today and post a link in here.

[Roxxik]

yesterday was a bit busy, but here it is: https://github.com/Roxxik/pcap-test
the code is quite ugly and uncommented since it's in the midst of a refactoring, but it works (after a quick fix that i just applied) so have fun with it ;)

EDIT: pushed some changes to my pcap branch, too

[stephanbuys]

@Roxxik and @vorner, I'm looking at this now - as murphy's law would have it I was busy on my own nonblocking fork when I stumbled across your thread here. Would be interested to hear if you made any more progress, or would be still be interested.

[vorner]

Sorry, it just sits somewhere deep in my TODO list :-|.

[stephanbuys]

@Roxxik, would you mind if I try and work your changes into an acceptable PR for @ebfull (I went off the path using the pcap_dispatch route)? That is @ebfull if you would be interested in having non-blocking/tokio support?

[ebfull]

I would be interested in that. 👍

[Roxxik]

Sure, go ahead

I had an application in mind that'd be using the feature, but for one i don't have too much time currently and second , i don't think i'm going to finish any of this soon

I haven't done any more than you can see online, but i'd love to look into your PR if it's done ;)

(i already desribed my application idea above, no need to repeat myself, more or less somthing like nethogs, but with some principled programming (have you looked at their, in my opinion, horrible c++?))

EDIT: just looked into #76 and i like what i see, and a lot of it looks familiar (haven't looked at my own solution for this problem for quite some time)

And i like how you picked up my convention of ma1n 1337-sp34k, that i just made up adhoc, because i heard you can do a main with a result type natively in the future, and just wanted to get it done quickly and then renaming ma1n to main, if the update lands

EDIT2: it's still a rfc: rust-lang/rfcs#1176

[ebfull]

This is done by #76! Woohoo!