Feedback: Sockets 2016

[rolandweber]

Before the exercise, I talked about message formats. Tried to compare text-based formats (HTTP) with binary formats. Introduced TLVs on a high level. We invented an example out of the Blue. Bad idea, didn't work.

After 60 minutes of coding, students were not done and wanted to continue. I stopped after 80 minutes of coding. Levels of completion:

• everybody managed to connect
• almost everybody could parse the returned token
• about half added the marker (or were working on that?)
• one group replaced tokens, another was working on that

About three quarters of the students afterwards considered the time as well spent.

Many students had problems with the "Think!" step. I noticed students trying to code without looking at other places where similar things are done, without checking standard JavaDocs on how to use a class, or without looking for locally available data. Several students failed to give their IDE project a decent name - I'll never understand these youngsters.

Some students mixed up tickets and usernames. They used only the last part of the ticket instead of the full ticket. Or they tried to return a ticket by passing the username instead of the whole ticket. Change the ticket format?

One group encountered problems with their IDE, IntelliJ. The project was configured for Java 1.3 instead of 7 or higher. The Main class was "not found" on execution. There were no such problems during the Tutorial. During the exercise, they unzipped the JAR file and created the IDE project from the files in the filesystem, rather than by importing the JAR. This might have been the difference to what they did in the Tutorial.

On the first attempt to request a ticket, the ticket is not shown because of the missing code. When trying again, the server responds with an error instead of a ticket, so the problem cannot immediately be reproduced. Requesting a second ticket is not possible, because the server tracks the client IP addresses. Returning the ticket is possible, but you have to read it from the server screen. In the worst case, students have to wait a few minutes for their ticket to time out.

[rolandweber]

Next year: Before the exercise, present the Binary Protocol of the exercise as an example. Talk about layers of abstraction (binary, TLV, application). JavaDoc walk-through of server-side classes. Point out the TLV helpers, which are also available on the client.

Defer comparison with text-based protocols to some other lesson.

[rolandweber]

I'll try a more guided exercise this time, intermingling coding steps with presentation. First something generic about client- and server-side sockets. Then something about layers of abstraction, maybe using the server-side JavaDocs for illustration. If I go into TLV details, I'll use the binary protocol as example.