Hello, Sorry for the previous very lengthy update. I'll keep this one short.
After several discussions the basic idea of how I'll implement transports is now clear. I have begun writing some basic plugin architecture. The same has been committed to the branch "refactor-1". I intend to finish, by the end of this week, refactoring portions of code from NodeCrypto. The main objective is to remove the "dependence on a single socket object" Currently I have submitted code on the following new classes- https://github.com/chetanhosmani/fred-staging/tree/refactor-1 1. TransportManager - This will now contain a list of available transports (packet transports and stream transports). Transports register here to let the node know of its availability. 2. TransportPlugin - A base class for the transports 3. StreamTransportPlugin - Base class for stream based transports. It mainly supports a "connect" method and a "listen" method. 4. PacketTransportPlugin - This is based on PacketSocketHandler itself. One issue I had was regarding opennet and darknet modes. So I have extended the plugins so that these methods know the mode of operation through a boolean. I am not sure if this is okay, though it is a bit crude. The plugin will provide separate sockets for opennet and darknet modes. The node side classes only need to mention this through the "isOpennet" variable. For the coming week the objective is to remove any "dependence on a single socket object". So I am working on it in the following way- Create TransportManager class for a node. Will list all transports irrespective of darknet and opennet mode. So this means there will be no issue when opennet is enabled later on. This will be followed by changing- NodeCrypto to handle new transports PeerNode to use new transports I am sorry I have not been able to update the flog. I will do some short updates there too. Regards, Chetan toad - Need specific advice on this part. Scenario 1 - transport plugin added after initialization of nodecrypto (say darknet). Scenario 2 - Opennet enabled after transport plugin is loaded. So transportmanager can be the class in between. 1. To handle new transports plugins coming in- Transport registers, TransportManager calls on NodeCrypto (maybe handleNewTransport(...) ) to handle the new transport for opennet and darknet modes 2. To handle new mode (opennet) after transport plugins are loaded The new nodecrypto checks for available transports and uses them at initialization. So I suppose it is okay to retain UDPSocketHandler as a default when transports are not yet loaded? I hope this is okay with you? Also as I mentioned here and on IRC, about using a boolean to distinguish between opennet and darknet, which the plugin takes care of. Is that also fine with you? Do let me know :)
