differentpla.net

The last couple of entries have shown the hex dumps of the individual packets. We'll step back to a slightly higher-level view now.

The first thing that emplode does when it contacts an empeg player is ask it what kind of player it is. Emplode needs to know this so that it can display the correct icon in the discovery window. I'll write up something about how empeg discovery works later.

The next packet that the empeg sends is the actual response to the OP_STATFID request. It looks like this:

0000   02 0c 00 07 01 95 00 81 80 00 00 00 00 07 00 00
0010   00 0c 00 00 00 7c 7c

(Don't worry; I'll stop showing the hex and I'll start talking about higher-level stuff shortly).

We've seen the format of the packet that emplode sends to find out the length of a file on the empeg (OP_STATFID). The empeg seems to always send a progress packet in response. The packet looks like this:

The format of the packets in the empeg's TCP/IP protocol owe a lot to the fact that the empeg mk1 communicated over a serial link. This means that there's a certain amount of cruft still in the protocol.

Most of this information is in the emptool sources, but I'm going to explain some of it in more detail here.

As revealed by Wireshark, the first thing that emplode asks for is the player's type. Let's take a quick look at the request packet:

I was bored this afternoon, so I thought I'd see how hard it would be to write an emplode clone in C#.

I've been playing around with learning C#. Today, I thought I'd write a C# program to find empegs on the local network.

It uses Socket.BeginReceiveFrom and Socket.EndReceiveFrom.