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.
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
(https://cwiki.apache.org/ETCH/architecture.html) 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.
Cheers,
Armin
