For computer networks we had a practicum assignment to write a protocol for a chat server and client. A protocol, in the sense of, a description of the procedures and keywords used in communication over the internet between the server and the clients. We had to program both the server and client in Java and demonstrate that they worked, i.e. that two people could actually communicate from two different computers.
But actually it was about the protocol, rather than the implementation. It should be simple and clear enough, and sufficiently well described, to enable other people to implement the client in such a way that they could actually connect to, and communicate over, our server. Which was what the next practicum assignment was about. The protocols were printed, put in closed envelopes, and then distributed among the groups. We had three hours to understand the protocol, implement a client, and then connect to the server of a different group and chat over it.
Sounds simple enough, doesn’t it? In fact it could have been, and it was for the two other people from our study group. They drew our protocol, and since it was straightforward, simple, and concisely described, they needed all of 20 minutes to connect to our server and start chatting. Lucky them! For we got a protocol whose completely unfathomable description was 14 structureless pages long. For all that bulk, it still managed to leave out all the important information, like how a protocol message should actually look like, or who the mysterious “recipient” of the message to the server was. It could have been anything, from the server IP, to the server name, to the room ID, or the room name. Luckily we had the author in the same room, and could figure this out.
What was worse was the bizarre message format prescribed by the protocol. For no apparent reason it wrapped everything in tons of angle bracket tags without any obvious structure. Any message to or from the server would be prefixed by a serious of header tags and then packaged into additional layers of nested tags different for any kind of message and devoid of even a trace of consistency. In our own protocol we managed to implement all necessary functionality with just five keywords and plain text messages for everything else. Yet this protocol needed a line of boilerplate for even a one-word message.
I was about to give up, or go and murder the author of this nightmare. What was he thinking, I wonder? He knew another group would have to implement this. Why on earth did he not keep it simple and to-the-point? Instead, he seemed to have had fun making his protocol as opaque and impractical as possible. My partner calmed me down, and we spent two frantic hours trying to at least get a basic communication with the server going, and we succeeded–just barely. We wrote logic that wrapped our simple commands into all this angle bracket boilerplate, different for each command, so the server would read it. We even started to parse the tag salad from the server into a human-readable format. I very much regret I wasn’t wearing my “People under pressure don’t think faster” T-shirt, though on second thought, maybe we did–think faster. Given the time pressure and the complexity of the task, it’s a miracle we actually got this going, because server socket communication and parsing messages is extremely error-prone at the best times. It was, in any case, a severe test for our resiliance to stress, and for our cooperation.
In the end the professor accepted our half-baked solution, possibly just as a sincere attempt to make the best of an impossible situation. It’s still only the third practicum assignment, but already this will be the hardest-won PVL ever in this course of studies–possibly worse than the nasty little tests in machine-oriented programming in the second term.