For my first networking project, I am working on a simple client/server chat, using TCP.

The idea was, make the communication lines (i.e. threads), and send packets over them (an id and packet-specific information).

It seems it works, but not consistently.

Here are some pictures to describe the problem:

Not working:

Working:

Left is server, right is client.

I get both of these result only by running it - no code changes involved. It seems roughly 25% of the time, it works.

The server has two lines at the top. The first is how many bytes were received. The second lists the bytes.

On the bottom of the client, it lists what bytes were written. The actual communication is through a DataOutputStream through the socket's OutputStream. I used another DataOutputStream with a ByteArrayOutputStream. In every place the first writes, the second does as well. It seems, then, that the bytes written does not change.

As for the bytes themselves. The first 0 is the packet id (there is only one packet currently). The load of this packet was a single string, a name. It seems writeUTF writes the length of the string as a short (two bytes, the next 0 and 3), followed by the characters.

The reason it fails when the bytes don't make it is that it reads the packet id correctly, tries reading the short for the length, but there is nothing left.

What might be causing this inconsistency?

The image links look broken for me.

Better now?

It seems it works, but not consistently.

This is usually a sign of a Thread problem: race condition or something else. But this is too complicated a situation without some code. Try commenting stuff out until you have the smallest example that exhibits the behavior. Odds are you'll figure it out before this, but if not, then you can post the code.

Also, try a network protocol analyzer to make sure it's really doing what you think it is doing... http://www.wireshark.org/

It will help if you share the portion of code where your server is reading and where you write to your server...

It will also help if you paste the code where you initialize your sockes and Input/Output streams.

A long while ago I made a simple little open-world 3D fps shooter using TCP, sort of a warm-up project to learn the ins-and-outs of game dev in some sense, and discovered the hard-way that TCP "packets" don't always arrive just how they were sent.. They can arrive in fragments, or clumped together with other packets, which requires a method for extracting and reconstituting the original packets.. At least, for programs like multiplayer games. Otherwise, this 'streaming' setup works great for things like file send/receive actions. This might be the issue you are having.

A long while ago I made a simple little open-world 3D fps shooter using TCP, sort of a warm-up project to learn the ins-and-outs of game dev in some sense, and discovered the hard-way that TCP "packets" don't always arrive just how they were sent.. They can arrive in fragments, or clumped together with other packets, which requires a method for extracting and reconstituting the original packets.. At least, for programs like multiplayer games. Otherwise, this 'streaming' setup works great for things like file send/receive actions. This might be the issue you are having.

That's really because TCP "packets" aren't packets. When you send() on a TCP socket you're really writing to a stream. That's the abstraction TCP provides. I think most people fall into this trap when they start out with TCP though... I know I did!

Sorry for the delay.

It appears I misunderstood TCP. Once I prefixed a packet length to sending it (and thus didn't read anything until enough information had arrived), it seems to work as expected.