[Twisted-Python] OSI 7 layer network model
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
> 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
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
More information about the Twisted-Python