[Verse-dev] Fwd: Verse in Java

[eskil at obsession.se]

Hi

I got a very interesting Email form Martin Smith (martin at spamcop  
dot net) who is working on a verse implementation in java! Its a very  
cool project and he had so good questions and comments i asked to  
re-post some questions he sent privately to me to the verse-dev list,  
he gave me approval so here is my reply to his questions:



>> > I've since done some work on a Java version of Verse, initially
>> > working towards
>> > a 100% Java client.
>
> Ok these are my current questions.
>
> 1. In section 3.5.2 it says "Packets are built by simply encoding commands,
> end-to-end, and pre-pending a 16-bit header." Does this refer to the  
>   packet ID?
> If so then shouldn't it be 32-bits? If not then what is this header for?

You are right packets have 32-bit headers. Emil has changed the spec.

> 2. Also in section 3.5.2 on the 1500 byte limitation. What happens if the
> application passes in a packet bigger than this?

Well UDP packets larger then 1500 bytes gets split up in to two by IP.
It is then re assembled in the other end under the hood. So it works.
However if one of them is lost both are, so you increase the
likeliness of lost packets by 100%, also one part has to wait for the
other so we introduce latency. This is why verse is designed to never
break the 1500 byte line as this is the break point for almost all ip
traffic (like ip on Ethernet).

> 3. The documentation appears to be missing an alias field for some    
> commands. E.g
> node_subscribe / node_unsubscribe. It's in the C code but not the docs.

That much be a spec error we are looking in to it.

> 4. The connect packet doc doesn't define what the address portion of  
>   the command
> is and I can't see this in the code.

No, Before the connection has been established no command comparison
is needed, because clients cant ask for re-sends.

> 5. During the hidden connect login I seem to get additional short    
> packets from
> the server. Are these acks or pings? What should be done with them?

They are acks. During connection all non connection commands should be
ignored. However you need to send acks on the connection commands
anyway. (more on this later)

> 6. Should a client retransmit the hidden login sequence if no response is
> received or is this an implementation decision?

Yes, if you are in any stage of an un completed connection you should
re send your latest packet (not command!) every second or so. You need
to do this because the Ack/Nak has not been established yet.

> 7. I can see complicated stuff in the C code for retransmitting a window of
> packets. Is this just something for the server to worry about or    
> does it affect
> clients as well? I was assuming retransmission of packets could be treated
> individually.

In the network kode, client and server is the same thing.

The code is a bit complicated, first of all the re send mechanism that
is required by spec is a bit complicated, but we have added some
implementation specific things to optimize. I would recommend looking
in to them.

Off the top of my head here are some of the optimizations we do with
sending and receiving.

-Every time you use any send command we look if there is something in
the out que that needs sending. (this speeds up wen you have a loop
sending a lot of stuff)

-Every time you send something we also look for incoming things, we
take out the acks, naks and process them before we process the packets
callbacks, we then store this packet so that we can unpack the
commands when the user calls verse_callback update(). this speeds up
the clearing of the history.

-We have two out queues, one sorted and one unsorted. This is because
the sorted queue becomes very slow if it is big so we have a unsorted
queue to get in to the sorted queue, this way we can have a maximum
size of the sorted queue and keep it from eating the CPU.

-We do check sums on all command addresses, then we put the commands
in a many "hash" so that we only have to compare commands with similar
command addresses. Also big CPU speed up.

-We have a special out queue for Naks and Acks. When ever we send
something we always empty this queue first, this way NaKs and Acks get
priority, and this makes the network go much faster. Actually this is
almost a requirement. Imagine that you have just one queue, and you
want to send a larger amount of data say one Meg, but your send window
is only 100K, you then send 100k, but all the acks you get will get in
the end of the queue so they wont be sent, if both sides end up in
this mode you are stuck, because both sides wait to get their
histories flushes but no one sends Acks that flushes them. So:
Naks/Acks doesn't _have_ to be given priority, but you need to handle
them slightly differently, because you need to send them even if your
window is full. And if you are treating them differently it makes
sense to give them priority while you are at it, because it will make
your implementation run so much faster.

> 8. Is there a keepalive in the protocol? I can't see it documented but the
> server seems to time out connections.

Yes there is. But the keep alive is in the form of Acks. One side will
send a ack, and then the other side will get that packet and send a
Ack for it, and when the first side gets that ack, and will send an
ack for that packet.... And then you have a loop. So the keep alive is
implicit. We have special exception in our implementation that checks
if all that is in the out queue is a ack, we wait one second to send
it. This mechanism is to reduce idle traffic.

If you don't hear anything from the other side in a long time, the
clients need to re send their last packet. This is because if you have
a keep alive loop and a packet gets lost you need to0 re start it.

The connection packets will produce acks too, this is to get the loop
started if the client connects with out actually trying to send any
commands. Early on we had some one who wrote a app that did not ask
for any data immediately and that app constantly got disconnected.

> I think that's all my current list. Any help with them would be useful.

Phew, long mail but keep sending them! if im unclear on something
please send follow ups.

Cheers

E