Java network error during file synchronization

Question

I'm currently working on a simple client/server file synchronization. For this, client and server follow a simple protocol which determines in which order messages are sent.

shortened protocol (Using Object/ByteArrayStreams):

Client loop:

1. Send filename
2. Send fileinfo
3. Send data
4. Wait for server confirmation

Server loop:

1. Read filename
2. Read fileinfo
3. Receive data
4. send confirmation to client

Repeat.

The problem is the protocol gets out of order when an error occurs during transmission and I usually get StreamCorruptedExceptions, since at least one side is expecting something else.

Here is a sample situation of the problem: Server fails during file reception (3) for whatever reason. Now the server waits for a filename. Because of the error, the client arrives at part 3 sending the data. Then the the Exception is thrown since the server expects a message object and the client sends byte data.

What is the best way to solve this?

Answer 1

some thoughts

• perhaps send acknowledge after each and every stage - it will be much easier to control
• The ack from the server can send a checksum that the client can verify the integrity of the transaction and move on. (md5 for example).
• implement a "stateless" server - i.e. server that can decide ad-hoc on which stage to serve, based on some "magic number" you can set at the beginning of each transaction (a header). That way, the client can retry any stage, and the server will be able to respond accordingly.
• you can expand the header to contain a unique id for unique files, so you will be able to parallelize the whole communication and upload multiple files in multiple stages, and from multiple clients.

Other thougt

• If you want to avoid the problem, instead of solving it, you can use very effective libraries to do that for you, instead of re-inventing the wheel. Check out protobuf - it's tricky to master, but extremely efficient, gson which is very easy to master, though less efficient, or many other off-the-shelf protocols.