GimpsterDotCom has (again) laid dormant while I’ve had other thing on my
mind… Even though I haven’t edited GimpsterDotCom in the last two
weeks, there has been some activity. A very friendly person has given the
PHP Tutorial a much needed grammar-check and fixed a lot of my bad
sentences — thanks a lot! It’s really wonderful to know that there are
people out there who want to help make GimpsterDotCom a better place.
I’ve spend the last five days on a DAIMI:dDistSik project together
with Mikkel Krøigård. And by “days” I mean from 9:00 to 24:00 (or
more) each day.
The project is actually very interesting, we’ve been asked to implement a
reliable connection-oriented transport protocol on a very unreliable
datagram-based network. Basically, this means that we were asked to
implement something like TCP upon something like IP.
So we started out with an enormously ambitious plan: we wanted to have our
transport protocol use the same credit based scheme as TCP employs. So we
sat down and read RFC:793 titled Transmission Control Protocol (TCP)
and started to work on the state-machine that should be the core of the
implementation.
But after having worked on this for a full day, we decided that it was too
difficult — RFC:793 describes the format of the packets, the states
of the sender and receiver and the actions that are to be performed when a
packet arrives, but it does so on a somewhat high level.
We switched from the cool, efficient, all-dancing, but complex credit-based
flow control mechanism to the terrible inefficient, but simple stop and
wait flow control mechanism. The most important difference between the
two is that with a credit-based implementation you have more than one
packet on it’s way from the sender to the receiver at any given time —
with stop and wait you send one packet and then waits until you get an
acknowledgment before you send your next packet. As one can imagine, this
is a very poor utilization of the available bandwidth.
But because we had started out with dreams about TCP (and we had even
started too late with that) we ended up with almost no time at all. And to
make things worse, then we somehow managed to implement the supposedly
simple stop and wait protocol in a rather tricky way which made it a
nightmare to debug. But we also had a huge number of problems with
getting Java to do as we wanted. Java is not very well suited to make
this kind of low-level programming where you have to fiddle with
individual bits in your header. In particular: Java doesn’t have unsigned
types and it insists on promoting smaller integral types (bytes and shorts)
to 32-bit integers before doing any bit-wise operations on them. That
would not be a problem if it were not for the fact that this widening also
does sign-extension! That surprised us a couple of times until we got used
to manually masking out the bits we wanted before using a variable with a
logical operator.
Despite all our problems, we managed to get it to work — we were finished
around 22:00 today with the programs and the report. We’ll be allowed to go
the exam When the report has been approved. This reminds me: don’t expect
to see a lot of changes here for the next month or so, because I’m having
my exams now. But if you have something to contribute, then please do —
it’s always a nice surprise to see something new here at GimpsterDotCom,
something that I didn’t write myself :-) So long!