Yes. Thank you.
On 15-05-2012 12:42, Chetan Hosmani wrote:
> On Tue, May 15, 2012 at 8:39 PM, Marco Schulze
> <marco.c.schulze at gmail.com> wrote:
>> What about changes to the FNP when stream transports are used? How much
>> power will transport plugins have on the actual bytes being sent? For
>> example, it might be advantageous for the TCP plugin to use some kind of
>> PAUSE-MESSAGE marker to allow messages with higher priority to be sent as
>> soon as they are queued, instead of buffering/fragmenting/packing messages
>> for pack transports.
> Well I am not the best person to answer all of those questions.
> If you check my previous two posts on devl, it explains how streams
> will be supported, and what power the transport will have.
>
> But to summarize-
> 1. Simply put the plugin will not deal with any of this, or at least
> the plugin developer will not have to worry about messages.
> 2. The plugin will deal mainly with setting up the low level
> sockets/streams, and returning them to fred
> 3. Plugin will deal with parsing the data to be sent, adding headers,
> etc. This is to allow stenography.
> This the plugin will implement by copying pipestreams from fred,
> encoding appropriately, and sending it on its own streams.
>
> Plugin will not perform any cryptography or tracking
> messages-in-flight as such. toad's idea is to make it as simple as
> possible. I will implement a TCP plugin only to demonstrate it.
>
> I have two parts here - stream support and extending packet support
>
> Now my job (stream based architecture will mostly be the later phases
> of my project) for stream architecture-
> 1. Have separate implementations of StreamMangler (to setup the peer
> i.e. do handshake, save keys etc.)
> 2. Have a separate thread StreamConnectionHandler that will fetch
> messages, track them, etc. You can call it analogous to
> NewPacketFormat. They run their own loop and communicate with stream
> based transports like TCP.
>
> I think here is where your suggestion applies. Although I am not sure
> I am the right person to comment on it. But I think it can be
> implemented.
>
> Also extending packet support would involve multiple NewPacketFormat
> objects running in parallel. The peernode would choose a transport
> based on availability.
>
> Another point is that each transport will use a single common message
> queue, but they track them independently.
> The objective is for multiple transports to setup and do handshakes,
> run and send messages simultaneously.
>
> A lot of work after that would involve choosing the right transport,
> latency issues and so on. I hope to get the basic running architecture
> ready first.
>
> I hope I have answered your question :)
> _______________________________________________
> Devl mailing list
> Devl at freenetproject.org
> https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
