File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Sockets and Internet Protocols and the fly likes TCP frame recieve at server pc but not at java program! Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Sockets and Internet Protocols
Bookmark "TCP frame recieve at server pc but not at java program!" Watch "TCP frame recieve at server pc but not at java program!" New topic

TCP frame recieve at server pc but not at java program!

Mandar Khire
Ranch Hand

Joined: Sep 11, 2007
Posts: 557

I write Server-client socket program. Run it on two different pc.
If i keep running Server side & client side program restart many times then after that server program not receive frame.
For that i cross verify by Wireshark application, i can see frame receive in wireshark but in server program console nothing happen.
here i post both programs.
here i not post what is contain in frame exactly. but in simple way it contains few int, short, string.

Server Program:-

In wireshark cross verify & find some differences as bellow:-
1. Coloring Rule String
2. Indentification
3. Header Checksum
4. Source port
5. in Transmission Control Protocol info Flag :- 0x19(FIN, PSH, ACK) in Not Ok frame & in ok frame its
Flag : 0x18 (PSH,ACK)
6. checksum : 0xc81a( correct) in Ok frame & in not ok frame
checksum : 0xc24f( correct)

If i restart server side java program & then try to send same frame from client program then it immediately receive in program.
Now my question is if i can see frame in wireshark then why not in java program?
1 more thing i want to share that in client side program
byte buffer is 100 byte but it contain only 58 byte actual.
today i will check whole thing by keeping accurate value for byte buffer size. but theoretically byte buffer size should not affect on working of server side program.
If i get clue/suggestion/solution/help then it will be helpful for me.

Millions saw the apple fall, but Newton asked why.
Jaikiran Pai

Joined: Jul 20, 2005
Posts: 10441

1) You don't need that server != null check on line 17 of your server code since you are assigning a new instance just the previous line.

2) I am not sure you need the isBound check either.

But neither of these are the problems from what I can understand of that code.

Two thing that you should note about that server code is:

1) You are doing blocking calls (like read) on the same thread as accepting new client connections. This can be a problem if the client tries to connect to the server and the server is already busy reading some data from some other connected client.

2) When you shutdown the client it can potentially trigger a IOException on the server side if it was in the middle of some blocking call like read. In your code that catch is outside the while(true) loop which means that the code which is meant to accept new connections (in that while loop) will no longer run. I think this is what is happening in your current case.

Edit: Having said all of that and then thinking a bit more, I don't see how the client will even be able to establish a connection in such cases when the server side socket isn't accepting the connection. The easiest way to really figure out what's going on is to take a thread dump of the server side code when the client tries to send some data after restart and see what's going on.

[My Blog] [JavaRanch Journal]
Domi Dori

Joined: Mar 23, 2014
Posts: 6
About your edit: The operating system accepts new tcp connections even when the thread is not in the accept call. Have a look at the backlog parameter.

This works as long as the server socket is listening and the backlog is not exeeded.
Jaikiran Pai

Joined: Jul 20, 2005
Posts: 10441

Domi, thank you for posting that. I wasn't aware of the backlog queue. Makes sense now.

I've awarded you a cow for stopping by to post that answer!
I agree. Here's the link:
subject: TCP frame recieve at server pc but not at java program!
jQuery in Action, 3rd edition