[Twisted-Python] OSI 7 layer network model

Glyph Lefkowitz glyph at twistedmatrix.com
Wed Dec 12 00:15:07 EST 2001


On Wed, 2001-12-05 at 15:06, Sean Riley wrote:
> I was wondering... how would you categorize the various pieces of Twisted in
> the OSI 7 Layer Network Model?
> 
> The layers are:
> 
> 1. Physical - hardware
> 2. Data Link - ethernet
> 3. Network - IP
> 4. Transport - protocols(TCP/IP, UDP)

When we start marketing twisted.internet hardware that you can use to
speak TCP/TIP, I'll let you know :-)

> 5. Session

It depends on the appplication.  Normally, this is managed by TCP itself
and is represented by a twisted.protocols.protocol.Transport instance. 
In broken, "stateless" protocols like HTTP, we have explicit session
management (twisted.web.server.Session); for many applications it's
unnecessary.  I guess in some cases this level doesn't exist?  When
you're using twisted.spread, the session is the Broker; Perspectives are
just one of the things that can be attached to the Broker.  Similarly to
web sessions.

> 6. Presentation

This apparently involves quite a few different things.  As you noted,
it's a computationally expensive place, this is where some optimizations
have already started to happen.  banana and jelly are at this level;
banana has been optimized into C.  (Yes, itamar, one of these days I
will integrate Elliot's changes)  Jelly is another candidate.

> 7. Application

"User Code", I guess :)

> I'm not sure how "session" fits in with Twisted. Maybe Perspectives play the
> role of sessions?
> 
> Presentation is defined as "where application data is packed/unpacked" -
> which seems to include both banana and jelly?
> 
> I'd like to be able to draw a diagram showing where python fits into this
> model and where the opportunities for optimization are found. By explicitly
> showing that the implentations of these layers are actually in C or provided
> by the OS, the perception that "python is slow" could be mitigated somewhat.

Well, at least 4.5 layers out of 7 are provided by hardware or C code
:-)  (Python itself is in C, after all; doesn't that make it fast?)

> I think that keeping the "session" layer in python can be justified with the
> added security of no buffer overflows, and the requirement for integration
> with the python application layer. There also are few tight loops in this
> layer.

After reading a bunch of OSI documents on this layer listing, I'm not
sure what *code* this layer actually refers to.  Session management and
flow control on the TCP level are done by the kernel; and a lot of
buffer overflows happen in the Presentation layer as well.

> The "Presentation" layer seems to be the most computationally expensive
> software layer as it includes encryptions, packing and compression. It is
> here that the pure python implentation is a little scary for most people -
> and so it is here where the most education and explicit categorization of
> components by implementation would be most useful.

More heavily optimized stuff at this layer would always be good, but I
would prefer to sacrifice as little safety as possible; there's always
the potential to mishandle data; especially if you count encryption in
this layer -- data which makes it through the encryption layer just fine
might still require processing that makes it dangerous to do in C.

That said, Twisted uses a C SSL implementation currently, and I
certainly have no plans to rewrite that in python.  I think that SSL is
probably good enough for the encryption layer, and it's well-tested.
Most of the problems I've had with it are build-related, although Moshe
may want to roll his own OpenSSL bindings to help resolve some of that.

-- 
______      you are in a maze of twisted little applications, all
|   |_\     remarkably consistent.
|     |          -- glyph lefkowitz, glyph @ twisted matrix . com
|_____|             http://www.twistedmatrix.com/






More information about the Twisted-Python mailing list