From: Aaron T. <syn...@gm...> - 2009-09-30 18:21:46
|
On Wed, Sep 30, 2009 at 10:21 AM, Abdelrazak Younes <you...@gm...> wrote: > Aaron, > My first thought is why? Why not just let the application developer handle > his thread? > > I've been using libpcap functions lately in a Qt GUI program and I just > needed to launch my libpcap function inside a QThread (I used QtConcurrent). > > The same could also be true for timers of course. Which means that you would > reuse the Qt event loop instead of your own. Basically, writing the timers for each platform and event looping is something which I've spent a fair bit of time working on to work as best as possible, and expecting any other developer to have to re-invent the wheel seems broken. Most solutions are at best 1usec accuracy (many only accurate to 10ms) which without a fair bit of effort aren't good enough for many users. > So my recommendation would be that the lib API focuses on the low level > ethernet sending/reading and let the application do the thread creation and > management. Then basically people should just use libpcap/winpcap (which provides a cross-platform means to read & write packets) and not use this API. Sure maybe they want packet editing, but they can already grab the tcpedit code which has it's own API today. Anyways, to be clear, I'm *not* suggesting the tcpreplay API do any thread management. Rather it is up to the application to manage threads as tcpreplay_replay() blocks until complete or until tcpreplay_abort() is called in another thread (both threads created/managed by the main application). Right now, I don't have any plans for a event loop based API (like libevent) since single threaded event loops like that don't provide enough control over timing. > Of course you can also provide a higher level API for programs > that do not want to bother with thread creation; and the tcpreplay console > program for example would use that high level API. And your proposed API > above fits quite well in this scheme. But I would also offer a lower level > API as outlined above. Non-multithreaded apps in my model would block on tcpreplay_replay() and not support the tcpreplay_abort() call (unless they handled it via a timer or signal handler). -- Aaron Turner http://synfin.net/ http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix & Windows Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin |