Hi Andrey, On Dec 11, 2007 5:00 AM, Andrey Tcherepanov <moyt63c02@sneakemail.com> wrote:
I like the idea of basic_message<> (which could be used for SMTP and gods know what else as well), but what about UDP servers or, generally speaking, multi-transport protocols?
basic_message<> is intended to be divorced from the actual transport being used to put the contents of it out the wire. The idea of basic_message is primarily as a common structure -- or the foundation -- on which all operations lower level (network transport, serialization/deserialization, etc.) and higher level (protocol specific transformations, chaining, stream operations, etc.) will deal with. If I only had the time and talent, I'll come up with a visual representation as to how the basic_message<> fits in all this network-related code with a simple layered design. For now, this is how I envision it: Adapters/Transformations Layer ---------------------------------------------------- | basic_message<> and derivatives | ---------------------------------------------------- Transport Layer For a client protocol 'stack', there will be protocol specific adapters and transformations higher than the basic_message<> abstraction and protocol specific derivatives. So the idea would then look like (for HTTP): HTTP Transformations/Adaptations Layer ------------------------------------------------------------ | http_request / http_response | both deriving from basic_message<> ------------------------------------------------------------ Generic/HTTP Transport Layer Question might be, what the transformations/adaptations layer would contain. There is no straight answer, but what comes to mind are the following: - Stream Adapters (create an HTTP Session "Stream", cookie support, ETags, etc.) - Iterator Adapters (turn a message or set of message(s) into iterator-accessible objects for STL friendliness; further examples can be imagined if there was more time to do it) - Protocol-Protocol transformations (example, HTTP<-->SMTP, or HTTP<-->XMPP, etc.) And the possibilities are endless. ;-)
Although http is sitting on top of TCP, there is an RTSP protocol which claims to be derived from HTTP/1.1 in most parts (well, at least RFC has lots of backrefs to HTTP spec), but allows to use connectionless transport (aka UDP). Moreover, RTSP treats Clients as something that can receive asynchronous stream change notifications (if allowed). I am not arguing that your design will not cover 95% of useful cases, but I think protocol parsing and transport layer might need more separation. This way if brave person will decide to implement RTSP (for example) as derived from HTTP, he/she will not be limited by TCP transport.
It will be divorced -- the concept of messages have nothing to do with the actual transport and processing that happens in a specific protocol stack. I hope this helps! :-) -- Dean Michael C. Berris Software Engineer, Friendster, Inc. [http://cplusplus-soup.blogspot.com/] [mikhailberis@gmail.com] [+63 928 7291459] [+1 408 4049523]