Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (526)
Games in Android Showcase (127)
games submitted by our members
Games in WIP (593)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Is TCP truly "guaranteed delivery"?  (Read 4523 times)
0 Members and 1 Guest are viewing this topic.
Offline neoskunk

Junior Devvie





« Posted 2011-03-07 06:21:16 »

Ok so i know TCP is supposed to be guaranteed delivery and delivered in the correct order but I have come across a situation where it would seem that a TCP "message" was lost all together.  Is this possible or is this a flaw in my code?

In detail:

I have a turn based game and it worked perfectly well for 3 or 4 games but on the 5th game a strange thing occurred where me and the person I was playing got stuck on a screen that said "waiting for opponent to take their turn."  However, I don't think the entire connection was blown since me and the other player could send "chat" messages back and forth (using the same port and socket).  Therefore leading me to believe that the data for my turn was simply lost.
Offline bobjob

JGO Knight


Medals: 10
Projects: 4


David Aaron Muhar


« Reply #1 - Posted 2011-03-07 07:16:58 »

its very likely that it is a problem in your code. I have never had a problem like that with TCP.

its more likely that a connection will time-out then send wrong information.

that said, if you are using Threading make sure information is accessed in order.

I would suggest going over your code thoroughly

My Projects
Games, Webcam chat, Video screencast, PDF tools.

Javagaming.org with chat room
Offline krasse
« Reply #2 - Posted 2011-03-07 07:20:39 »

Tcp can timeout but not get lost without a trace.

I would check all try-catch in my code to see if an exception gets lost somewhere.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline neoskunk

Junior Devvie





« Reply #3 - Posted 2011-03-07 08:03:40 »

ok thats what I was thinking but just wanted to make sure.  Just to clarify, there is no possible way that messages will get out of order either right?  Meaning if there is a problem with a certain message the connection will timeout rather than send the next message?
Offline bobjob

JGO Knight


Medals: 10
Projects: 4


David Aaron Muhar


« Reply #4 - Posted 2011-03-07 09:49:51 »

ok thats what I was thinking but just wanted to make sure.  Just to clarify, there is no possible way that messages will get out of order either right?  Meaning if there is a problem with a certain message the connection will timeout rather than send the next message?
if a problem with data or a "message" is found in the connection then TCP deals with it, and would likely send the required data again, so that it is recieved in order. Only a time-out would cause a time-out.

Granted TCP can run into other problems for example, in your code you could possibly be trying to recieve the wrong kind of data.
eg. when sending an int, and trying to recieve a UTF.

TCP issues are rarely illusive.

My Projects
Games, Webcam chat, Video screencast, PDF tools.

Javagaming.org with chat room
Offline pjt33
« Reply #5 - Posted 2011-03-07 15:57:35 »

Just to clarify: you are talking about keeping a single connection open and sending multiple messages down it?
Offline neoskunk

Junior Devvie





« Reply #6 - Posted 2011-03-07 19:12:38 »

Just to clarify: you are talking about keeping a single connection open and sending multiple messages down it?

Yes I am.

However, I currently send everything as a string and parse it for whatever data is needed. I'm going to check my code must be my mistake. Thanks for the info guys.
Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #7 - Posted 2011-03-08 18:56:00 »

In multiplayer games, log log log. Every time any message is received or sent it should be appended to a giant log file (or just the console if you want). That way you can look for "sent turn end packet" and "received turn end packet," then trace when and where each of those things happen.

See my work:
OTC Software
Offline neoskunk

Junior Devvie





« Reply #8 - Posted 2011-03-10 00:22:15 »

Eli can you be more specific?  How does logging help me?  And I'm assuming you mean on the server side program?  Or server and client?
Offline ddyer
« Reply #9 - Posted 2011-03-10 00:45:50 »

Tcp is only guaranteed at the lowest possible level where the OS receives the data.  There is plenty of code between that and your application where bugs can occur.  That said, the by far most likely place for data to get lost is in your own code.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline philfrei
« Reply #10 - Posted 2011-03-10 09:14:06 »

Are both sides "waiting for the opponent"? That sounds more like a deadlock condition, each side waiting for the other to release a needed resource.

Sure, log everything at the lowest possible level. Then you know will know for sure what got sent and when.

"It's after the end of the world! Don't you know that yet?"
Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #11 - Posted 2011-03-10 22:26:16 »

Eli can you be more specific?  How does logging help me?  And I'm assuming you mean on the server side program?  Or server and client?
I mean on both. And if possible you can combine the logs into one single log based on timestamp. You basically need to do this to figure out if you've got a deadlock like philfrei suggests or something else.

Try testing extensively on localhost so that you can figure this one out, it will be much easier to trace exactly what is happening then trying to figure stuff out remotely. That's just my opinion, though, depending on your setup this may not be the case.

But if you do it locally you can use breakpoints, which are a big win.

See my work:
OTC Software
Offline neoskunk

Junior Devvie





« Reply #12 - Posted 2011-03-12 08:17:56 »

Ok yea that makes sense, at least for testing on a local machine I can see why that would be useful.

Like philfei suggested it was where both opponents were waiting.  However, it was not something that I could duplicate and still haven't seen it happen since.  Thus I was wondering if TCP could possibly just lose information that way (my original question).

Abstractly this is how my game functions:

p1 connects to server.
p2 connects to server.
when two players are connected the server pairs them and creates a game.

p1 takes his turn.
the turn is animated on p1's applet.
the information from the turn is then sent to the server.
server does necessary checking for cheating etc. and send the turn to p2.
p2 then animates p1's turn.
p2 then takes his turn.
...
cycle repeats.

the game froze after I took my turn.  the turn was successfully animated on my applet.  thus I would think that data was also sent.
this is where logging would have been helpful.

it just seemed strange to me that it was such a random occurrence.  however the game has not been thoroughly tested thus maybe the occurrence isn't so random.

i'm going to set up a log and that should get me moving in the right direction.  if anyone thinks the abstraction part above doesn't sound like I'm doing something correctly let me know.
Offline ddyer
« Reply #13 - Posted 2011-03-14 00:54:55 »

Are both sides "waiting for the opponent"? That sounds more like a deadlock condition, each side waiting for the other to release a needed resource.

Sure, log everything at the lowest possible level. Then you know will know for sure what got sent and when.

Another common variation, if you're using blocking I/O, is for a process to block because it's output buffer
is full, while the receiver is also blocked either for the same reason or because it is waiting for a response
that it thinks ought to be in the pipeline somewhere.  You should not depend on the buffering
capacity of the TCP stream.  You should never wait synchronously for a response.   

My games have a
(a) a reader thread that reads messages from the TCP stream and queues them for the game
thread to process.
(b) a game thread that processes messages from the reader thread (and also other sources of input
such as the mouse and keyboard).  It queues outgoing messages for a writer thread to deliver, but
never waits for them to be sent.
(c) a writer thread that sends messages that were queued for it to send.
Offline neoskunk

Junior Devvie





« Reply #14 - Posted 2011-03-14 01:21:11 »

 

My games have a
(a) a reader thread that reads messages from the TCP stream and queues them for the game
thread to process.
(b) a game thread that processes messages from the reader thread (and also other sources of input
such as the mouse and keyboard).  It queues outgoing messages for a writer thread to deliver, but
never waits for them to be sent.
(c) a writer thread that sends messages that were queued for it to send.


I do something similar for receiving but I never thought of doing that on the sending part.  I have a thread that queues messages that are received and then processed by the update thread of the game cycle (ie. update, render, draw).  Even if this isn't my problem doing it for the sending part would be a good idea.  Thanks for the info.
Offline delt0r

JGO Knight


Medals: 30
Exp: 18 years


Computers can do that?


« Reply #15 - Posted 2011-03-16 23:03:43 »

While TCP is "reliable" it should be noted that a connection can go dark without throwing exceptions per say. That is the connection become a black hole direct to /dev/null. I have noticed to get solid TCP reliability i need to have my own timeouts where i then treat this the same as a socket exception (connection closed by... etc).

Also since you are using strings you can use something like tcpdump to see your network traffic.

I have no special talents. I am only passionately curious.--Albert Einstein
Offline neoskunk

Junior Devvie





« Reply #16 - Posted 2011-03-17 00:04:54 »

While TCP is "reliable" it should be noted that a connection can go dark without throwing exceptions per say. That is the connection become a black hole direct to /dev/null. I have noticed to get solid TCP reliability i need to have my own timeouts where i then treat this the same as a socket exception (connection closed by... etc).

I have heard of this happening previously.  However, I was under the impression that setting a timeout using .setSoTimeout() would allow this condition to be caught?  I have set up a ping-pong type communication between the server and the client per a suggestion in a previous thread.  I was under the impression that if a thread blocked on say in.readLine() for longer than the time set with .setSoTimeout() a socket exception would be thrown.  Is this incorrect?
Offline delt0r

JGO Knight


Medals: 30
Exp: 18 years


Computers can do that?


« Reply #17 - Posted 2011-03-17 09:26:11 »

I was under the impression that if a thread blocked on say in.readLine() for longer than the time set with .setSoTimeout() a socket exception would be thrown.  Is this incorrect?
I think that is correct. I am currently using non blocking IO. I would test it at anyrate, network code should never assume.

This problem happens in TCP when say your ISP gives you a new IP number. Now all the packets from the old TCP connection are not coming to you anymore, and no error or control packets were sent by either side. Basically it looks like a black hole of /dev/null. No matter how you set up the hand shaking you still have what is called the 2 generals problem, and that means that control packets can get lost and the connection goes dark without errors. TCP does have a keep alive, but IIRC it is typically very long/slow.

I have no special talents. I am only passionately curious.--Albert Einstein
Offline Mr_Light

Senior Devvie


Medals: 1


shiny.


« Reply #18 - Posted 2011-04-13 20:30:54 »

TCP does have a keep alive, but IIRC it is typically very long/slow.
you can configure how long the keep-alive is.

make sure you flush your socket at the end of each message. if you message is too small the nagels algorithm will cause it to stay in the buffer indefinably if theres never any more data your trying to send.

even if the socket does time out at some point, you will not get an exception until you actually call anything on the socket. TCP once it hits the wire is do or die. if it doesn't die, it did which is what guarantied with respect to TCP means.(also in a large sense, but explaining that is entirely fuzzy. it related to how real-time!=fast)

It's harder to read code than to write it. - it's even harder to write readable code.

The gospel of brother Riven: "The guarantee that all bugs are in *your* code is worth gold." Amen brother a-m-e-n.
Offline delt0r

JGO Knight


Medals: 30
Exp: 18 years


Computers can do that?


« Reply #19 - Posted 2011-04-14 09:01:52 »

I have the nagels algo turned off for all my game tcp connections. I ensure that i am not doing anything silly like sending a single byte at a time.

I have no special talents. I am only passionately curious.--Albert Einstein
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

toopeicgaming1999 (73 views)
2014-11-26 15:22:04

toopeicgaming1999 (62 views)
2014-11-26 15:20:36

toopeicgaming1999 (15 views)
2014-11-26 15:20:08

SHC (29 views)
2014-11-25 12:00:59

SHC (27 views)
2014-11-25 11:53:45

Norakomi (32 views)
2014-11-25 11:26:43

Gibbo3771 (27 views)
2014-11-24 19:59:16

trollwarrior1 (40 views)
2014-11-22 12:13:56

xFryIx (78 views)
2014-11-13 12:34:49

digdugdiggy (56 views)
2014-11-12 21:11:50
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!