This is our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

We have some issue on our production environment. In normal condition, communication between two servers(JBOSS application server and SQL 2005 database server) works perfectly.

But In some situation, two servers(JBOSS application server and SQL 2005 database server) can communicate with each other for small data (20 records) but communication fails with slightly large data(1000 records). Once this problem happens we have to restart the machine( the server on which JBOSS application server is deployed) to resolve the problem.

Note: After restarting the machine(the server on which JBOSS deployed) communication works perfectly (i.e. even with large data).

We are doing wireshark packet capture for this problem. It shows following warning in analysis.

1)4 NOP in Row

2)Zero Window

What is meaning of above warning? Can these warnings are related to disconnect problem? Any suggestion to isolate the issue would be great help to us...

asked 25 Mar '11, 00:04

Maulin's gravatar image

Maulin
1111
accept rate: 0%

retagged 25 Mar '11, 02:33

packethunter's gravatar image

packethunter
2.1k71548


NOPs "No Operation" might not be a problem, they're often used as a keep-alive mechanism to prevent an established session from being terminated (especially if it has to pass a firewall with state timeouts).

Zero Window is a problem if it is not a reset packet (which Wireshark should not mark as zero window). The TCP window is a receive buffer that gets filled with packets coming in from the sender. If the OS or the application doesn't process incoming data fast enough the remaining buffer (the window) will become smaller and smaller. If it hits zero the receiver tells the sender that it cannot process any more data until further notice (usually through a "window update", but the sender can also test if he can continue using "window probing").

If you encounter zero window problems you are usually facing an overworked receiving station, it is not a network problem but the receiver is not capable to process incoming data fast enough. You should investigate if you can improve the receivers performance by tuning the hardware, the OS settings or (worst case) the application.

permanent link

answered 25 Mar '11, 01:24

Jasper's gravatar image

Jasper ♦♦
23.8k551284
accept rate: 18%

Just to support Jasper's statement - you can use "netstat -an" command (should be available on most of the platforms) and 2nd column should show you nos. of packets that are waiting in Q for processing. You can try to tweak "tcp read buffers"

permanent link

answered 25 Mar '11, 01:32

Vijay%20Gharge's gravatar image

Vijay Gharge
36151620
accept rate: 0%

Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×19
×1

question asked: 25 Mar '11, 00:04

question was seen: 6,774 times

last updated: 25 Mar '11, 02:33

p​o​w​e​r​e​d by O​S​Q​A