> -----Original Message-----
> From: javagroups-development-admin@...
> [mailto:javagroups-development-admin@... Behalf Of
> Bela Ban
> Sent: Wednesday, June 20, 2001 12:19 AM
> To: JavaGroups
> Subject: Re: Rif: [Javagroups-development] Message size and header
> John Georgiadis wrote:
> > Although this approach is very appealing: parameters are negotiated at
> > join-time thus they are not hardcoded, joining must be as
> _lightweight_ as
> > possible.
> I agree. But we could fetch these parameters *after* we join the
> group. I use
> this principle for example in FD_SOCK: I join a group and after
> having joined
> (in the VIEW_CHANGE event), I retrieve the cache from the coordinator.
In this problem we have to take in account that there can be many partitions
and all must have the same mapping.
I think that a layer placed above the network layer can queue compressed
messages and request to peers the mapping.
> > In my opinion, a simple hardcoded mapping of unique ints (or
> just shorts!)
> > to header class objects (class objects are singletons and have unique
> > hashcodes) is ok, it is lightweight, clean and simple, the
> mapping placed in
> > a hashtable.
> > Registering a number for a new header is not so bad, e.g.
> /etc/services uses
> > this scheme.
> I agree. Not the cleanest solution, but doable and very efficient.
This can be done with a mapping (only for often use headers) contained in a
dedicated layer without changing too much the architecture of classes.
> When we look at Message, which is what is sent between processes,
> there are the
> following members:
> dest_addr (Address): the address of the receiver. Null for
> multicast messages,
> an IpAddress for unicast messages
> src_addr (Address): the address of the sender. Always non-null (IpAddress)
> buf (byte): when null, we send 0. Otherwise, we send the number
> of bytes and
> then the byte array
> headers (Stack): we write the number of elements, and then each element
> (subclass of Header)
> Looking at compressing messages, we definitely need to compress Headers.
> However, what about dest_addr and src_addr ? This problem is similar to
> Headers, because these 2 fields are subclasses of Address as well. Each
> IpAddress consists of an InetAddress and a port. We could use the
> same scheme
> as for Headers to transmit the class (e.g. IpAddress, ATMAddress
> etc) here. But
> it seems that InetAddress is the problem: we could easily only
> transmit the
> byte buffer (InetAddress.getAddress()), but there is no constructor that
> creates an InetAddress from the byte buffer. Using
> InetAddress.getByName(hostname) is probably too slow as it
> contacts /etc/hosts,
> DNS etc.
> The issue is all the more important, because we usually have a
> large number of
> Address instances, but most of them are the same, e.g. the set of
> addresses of
> all group members. So if we could maintain a dynamic cache of
> IpAddresses and
> numbers, we would be able to send only the numbers after initial
> A first thought was to use the ordered membership list, and only
> send indices
> instead of addresses. However, the membership changes, and
> indices might be
> wrong, which could lead to some very subtle problems.
> Any comments/suggestions on this ?
> Bela Ban
> Fujitsu Network Communications
> (408) 895-1732
Addresses in the message are generated by the network layer and can
therefore be serialized knowing the class.
I think that addresses have to be added to messages only if they are not
null, in the other cases they are contained in the received datagram, so
adding they to the message is redundant.
So if we found a way to give to the "network layer" a message with no
headers (group name should also be handled by a layer above) containing a
compressed serialized version of a message we can send it in the best
My 2 lire.