etch-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Armin Müller <>
Subject Re: [jira] [Created] (ETCH-157) UDP implementation for Java, C# and C binding
Date Fri, 29 Apr 2011 14:48:56 GMT
Hi Holger & Michael,

> 0005: 
> provides UDPConnection for Java. We have seen that you skipped the Packetizer for this.
> 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 all

> 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.


View raw message