Home Original page

OO design and multiple local sockets

Andrew McGregor andrew at indranet.co.nz
Thu Jan 30 08:28:29 EST 2003 
--On Friday, January 31, 2003 00:23:35 +1100 Andrew Bennetts 
<andrew-pythonlist at puzzling.org> wrote:

> On Fri, Jan 31, 2003 at 01:36:12AM +1300, Andrew McGregor wrote:
>> I've got an awful case of writer's block on this one :-(
>>
>> Problem:  I'm writing an app (an implementation of HIP, see
>> www.hip4inter.net) that uses raw sockets in a big way.  It needs to bind
>> local sockets to each IP address on the system so it can transmit
>> packets  with each source address.  It also needs to know which address
>> packets were  received on, and from where.  So far, so good.  It's
>> threaded (pretty much  necessarily).  There are two pools of sockets for
>> two different protocols  that have to interact.
>>
>> Just the code for the protocol transforms and state machines is about 7k
>> lines, including tests, and works, but with only a single unbound local
>> socket, so some features I can't do yet.
>>
>> What I can't figure out is what a clean OO design for the socket
>> handling  looks like, managing the various queues and worker threads
>> without getting  really hairy.  Can anyone help?
>
> For OO design inspiration for socket programming, I suggest looking at
> Twisted <http://twistedmatrix.com/> -- although admittedly it is rather
> different to your design (being single-threaded asynchronous rather than
> multi-threaded).  In particular its Factory and Protocol classes may be of
> interest.
>
> In fact, I'd really tempted to use Twisted for this -- have you looked at
> it?  I've found it excels for writing servers that involve multiple
> protocols.
>
> (Not that being a developer of Twisted makes me biased or anything...)

It looks interesting, and I'd be perfectly happy to use the event model, 
especially since the HIP specs are more-or-less written that way.

However, I can't see how to convince Twisted to use a raw socket.  The 
second issue, less serious, is that some operations in the protocol can 
take several seconds of CPU time, which should ideally be done in the 
background wrt the fast actions of other connections; these can usually be 
done in a few milliseconds.  Mind you, threads don't solve that entirely 
either, because the GIL gets in the way.

Andrew

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20030131/4ea39573/attachment.sig>
More information about the Python-list mailing list