Re: The Erlang way - dynamic upgrade of a server and UBF extensions

I like clear, clean, simple, regular data structures.  Especially
in a functional language they make for obvious code.  One
thing I've always felt was missing in data protocols is the
versioning on every packet.  I think that is an essential feature.

The IP failover seems to handle a reasonable case of
essentially connectionless single packet transmission,
or the equivalent of frequency hopping.  More complex
failover can be part of a data packet listing multiple IPs
or a hierarchy or mapping to particular versions of the
protocol, as agreed in UBF(B) or UBF(C) contracts.

I like the idea of always having a packet header.   It is much
simpler if the size of the packet is specified, but I wonder if
that is too much of a burden on the client.  I would rather:

<<Length:32>> = gen_tcp:recv(Socket, 4),
Packet = gen_tcp:recv(Socket, Length) ...

then to parse a stream a few bytes at a time calling recv.


Trying to come up with a header runs into three problems:

1) If packet size is first, 4 bytes might be wasteful to a small
msg protocol.

2) If version comes first to determine the size of the packet
length field, either a fixed version size (too limiting) is needed
or the integer UBF(A) spec is used with byte by byte recv parsing.

3) Having a size at the front means the client has to assemble
the whole message, compute the size and then send all, rather
than streaming out data.

Not sure who should have the easier job, the client or server.
Given that the client is written more often (and probably by a
wider range of programmers of varying skill level) I would guess
it is better to make things easy on the client.  That would argue
for a header as Joe proposed without a length and the version
coming first (presumably an integer in UBF(A) format).  The
server has to do byte by byte gen_tcp:recv in this scenario.

jay