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/