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.schu...@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@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
_______________________________________________
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
