tcp connection splitter

Mike Meyer mwm-keyword-freebsdhackers2.e313df at mired.org
Thu Apr 12 20:00:45 UTC 2007


In <20070412190849.63355.qmail at web27705.mail.ukl.yahoo.com>, Daniel Taylor <daniel_h_taylor at yahoo.co.uk> typed:
> data/second), a lot of memcpy()s, and doesn't scale
> very well.   Also, adding a packet to N queues is
> expensive because it needs to acquire and release
> N mutex locks (one for each client queue.)

You can't escape that with this architecture. In paticular:

> Each
> enqueue bumps the refcount, each dequeue decreases it;
> when the refcount drops to 0, the packet is free()'d
> (by whomever happened to dequeue it last).

These operations have to be locked, so you have to acquire and release
1 mutex lock N+1 times.

The FSM model already suggested works well, though I tend to call it
the async I/O model, because all your I/O is done async. You track the
state of each socket, and events on the socket trigger state
transitions for that socket. The programming for a single execution
path is a bit more complicated, because the state has to be tracked
explicitly instead of being implicit in the PC, but *all* the
concurrency issues go away, so overall it's a win.

	<mike
-- 
Mike Meyer <mwm at mired.org>		http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.


More information about the freebsd-hackers mailing list