Jump to content

  • Log In with Google      Sign In   
  • Create Account

Inconsistent Sending of Data


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
7 replies to this topic

#1 ForestBit   Members   -  Reputation: 107

Like
0Likes
Like

Posted 30 June 2014 - 09:13 AM

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:

33mly7d.jpg

 

 

Working:

 

33otrnc.png

 

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?


Edited by ForestBit, 30 June 2014 - 10:24 AM.


Sponsor:

#2 hplus0603   Moderators   -  Reputation: 5301

Like
0Likes
Like

Posted 30 June 2014 - 09:20 AM

The image links look broken for me.
enum Bool { True, False, FileNotFound };

#3 ForestBit   Members   -  Reputation: 107

Like
0Likes
Like

Posted 30 June 2014 - 10:24 AM

The image links look broken for me.

 

Better now?



#4 Glass_Knife   Moderators   -  Reputation: 4423

Like
1Likes
Like

Posted 30 June 2014 - 12:13 PM


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/


I think, therefore I am. I think? - "George Carlin"
Indie Game Programming

#5 krinosx   Members   -  Reputation: 539

Like
0Likes
Like

Posted 30 June 2014 - 12:56 PM

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.



#6 radioteeth   Prime Members   -  Reputation: 1045

Like
2Likes
Like

Posted 30 June 2014 - 10:15 PM

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.



#7 Bacterius   Crossbones+   -  Reputation: 8827

Like
0Likes
Like

Posted 30 June 2014 - 10:25 PM

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!


The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

 

- Pessimal Algorithms and Simplexity Analysis


#8 ForestBit   Members   -  Reputation: 107

Like
0Likes
Like

Posted 02 July 2014 - 07:34 PM

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.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS