Nice! Which transport plugins you are planning to implement?
On 15-05-2012 04:13, Chetan Hosmani wrote:
> 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 :)
> _______________________________________________
> Devl mailing list
> Devl at freenetproject.org
> https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
