gm-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gm-devel] Thoughts on the future of ProtocolManager, etc.


From: Jesse Lovelace
Subject: [Gm-devel] Thoughts on the future of ProtocolManager, etc.
Date: Mon, 01 Jul 2002 11:23:24 -0400
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020513

Henrik;

I have been thinking about our new design situation and the role the our Managing classes will have in it. I see the Protocol Manager keeping all the sockets and protocols in check, individual protocols report to the Protocol Manager, and the ProtocolManager reports to the Session Manager. Inside the SessionManager, data is decrypted if necessary, and passed along to the use, wether by a gui or text based interface. (view fixed-width)


--TOC--> |                |    |              |
--MSN--> | Protocol Mngr. | -> | Session Mngr | -> User
--GNU--> |                |    |              |

The reverse is also true, the user will try and send a message to a "contact", session manager will see if: (a), any of the contact's networks are active, (b) if the contact is logged in to an active network. If so, the session manager will send a messsage to that contact via the prefered network. Only the session manager should access the AuthLoad system. The session manager will also house the ssh2 tunneling system.

ProtocolManger does need a data-only pass-through for networks such as peer-2-peer which are really just ssh2. For all other networks, we will baseXX encode our data so it can be sent as text. The Protocol Manager will recieve messages and if they are longer then the maximum length per message for the specified network, it will send them multi-part in a series of chunks.

These are my thoughts, please give me your comments.


jesse




reply via email to

[Prev in Thread] Current Thread [Next in Thread]