etch-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From scott comer <>
Subject Re: [jira] [Created] (ETCH-157) UDP implementation for Java, C# and C binding
Date Fri, 29 Apr 2011 16:03:38 GMT
for what  it matters, the packetizer was about chopping a stream into 
packets, obviously not needed for udp. the udp transport itself will 
reject packets which are too big.

where it is desired that a larger message is chopped into multiple 
segments, that might be interesting to both udp and tcp transports. 
let's call that the segmenter and consider it part of the larger 
discussion of issues around big messages?

scott out

On 4/29/2011 9:48 AM, Armin Müller wrote:
> Hi Holger&  Michael,
>> 0005:
>> provides UDPConnection for Java. We have seen that you skipped the Packetizer for
>> This is certainly reasonable for UDP, since you don't have multiple Packets for
>> one message. On the other hand this also means you change the wire format (the
>> packetizer also adds the signature and the package length at the beginning). I
>> would suggest to keep the Packetizer in the chain even for UDP, still adding
>> signature and length fields.
> we skipped the Packetizer for two reasons:
> - it is not necessary for UDP
> - the architecture images on the website
> ( also skip the Packetizer
> It depends on what is more important. Either skipping the Packetizer and
> having a minimal package length or adding the Packetizer and having the
> same wire format (e.g. for analyzing it with Wireshark). Surely adding 8
> byte per message wouldn't have much impact on the performance, but for
> UDP these 8 byte aren't necessary.
>> I would furthermore suggest to use the Packetizer
>> to check, whether the length of the serialized message fits into one UDP datagram
>> packet. The Message should be discarded with an error, if this is not the case.
> The Packetizer shouldn't check if the serialized message fits into one
> UDP datagram, because it works protocol independent. It doesn't know if
> it is used with TCP or UDP. Checking the UDP datagram length should be
> done in the UdpConnection implementation.
>> But I have already applied the other patches for Java (Signals, singlesession)
>> just for testing, too. I would like to start a discussion regarding
>> singlesession in that context. You added this due to the fact that you don't
>> want to build up the entire etch stack for every udp peer. This is (in my
>> opinion) mainly due to resource usage reasons (no multi threading). The same
>> could be achieved in an implementation similar to Non-Blocking IO (implemented for
>> TCP/Java in util...nio, TCP2Connection). Did you have a look at this? The problem
>> is that UDPConnection also extends Connection, which is a Runner, which is basically
a Thread
>> (for every Connection).  Wouldn't it be nicer to have a single thread which handles
>> the UDP peers, but still having multiple Etch Stacks (stubs+remotes)
>> for every peer? That would enable Callbacks as far as I can see until now.
>> Wouldn't this be a nicer way of doing the same thing for UDP? Could you explain
>> your rationale on implementing singlesession a little bit more?
> Tcp2Connection is very nice for having only one thread and is currently
> only available for the Java binding. But besides reducing the threads we
> also wanted to reduce the number of Etch Stacks (messagizer, stubs and
> remotes), because in some scenarios we don't care about the remote
> clients (i.e. track their state) and in these scenarios it is not
> necessary to instantiate Etch Stacks for every client.
> Single sessions are for example useful when peers send broadcast
> messages (e.g. to announce their availability). In this case we just
> want to receive the notification. If the receiving peers would
> instantiate for every new broadcast sender a new Etch Stack, they can't
> decide when the sending peer is not available any more and the list of
> instantiated Etch Stacks would continuously increase. Etch is based on
> assuming that every connection is stream based, but with UDP also
> scenarios without streams are possible, like in the broadcast scenario.
> We have used broadcasts and single session mode to implement a service
> discovery mechanism without a naming service.
> Signals add the ability to explicitly subscribe for certain messages. In
> contrast to pure one way messages from servers to clients they are only
> sent when a client is interested in these messages. In multiple session
> mode the message is sent to exactly one client. With single session mode
> it is additionally possible to send one message to multiple clients. In
> multiple session mode the application would need to manually keep track
> of connected clients like in the chat example.
> Cheers,
> Armin

View raw message