Thank you. I have a small Web site that makes a Ajax "GET" request every 200ms to a Web server. The Web site wait for a small document (750 bytes) from the server, it displays the document data before to send a new request to the server. The document is updated periodically every 200ms by another process (priority superior than web server'one). There is no synchronization between two processes. So, the reading task (web server) may be interrupted from time to time by the writing task, but not for long time. The data in the document could be error some times, but it is not a big problem, because the data is only for display, in addition we check data and display only if data is good. The problem is that our application is stopped after some hours of run, and always after reception of a "Continuation or non-HTTP traffic" packet. And the web site doesn't know to detect this case. As the packet "says" the data is not finished, it is keeped to wait some packets more that never arrive, so it is blocked. I think it is an error coming from the server side, but is it possible to fix it in the web site or not ? Case OK from Wireshark (during some hours) :
case not OK from Whireshark :
Following is the source code of the web site :
Thank you very much for help. NewportMicro asked 18 Jan ‘13, 06:41 NewportMicro edited 18 Jan ‘13, 10:47 Guy Harris ♦♦ |
3 Answers:
without knowing any details about your OS (realtime or not), and the file update process, I believe you are running
Race condition: One process opens the file for a write operation and possibly writes some bytes, then the next process (web server) opens the file for reading. This will end up in unpredictable results. I suggest to redesign the whole process of updating the information in the file. From the information you gave, there should be some synchronization between the update process and the web server process. Bug of the update process: Another possible error could be: the update process itself is buggy and writes a bogus file after some time (did you check that?), which would explain why you run into this only after a few hours. As @SYN-bit said, without a capture file it is hard to analyze. But even with a capture file, you may not see the real reason for the problem, without analyzing the problem on the system itself. Regards answered 21 Jan '13, 07:34 Kurt Knochner ♦ edited 21 Jan '13, 07:40 |
I have looked at your tracefile and found the cause of the problem. If you filter with "tcp.stream==1308" you will see that the server responds with a "Content-Length:754" header, while in fact the content is 756 bytes long. The webserver should respond with the correct content-length. So you have to be aware that the file can get written to between functions. So if your code looks something like this:
You might get into this kind of problem (when a new file is being written between the getLengthOfFile() and readFile()). Also, your client code could be made more robust in handling errors and exceptions. answered 29 Jan '13, 06:33 SYN-bit ♦♦ Great. Thank you very much for the excellent analyse. I will do as you did and then inform to you the result. Have a nice day. (30 Jan '13, 01:10) NewportMicro |
I can think of a couple of reasons why wireshark displays the HTTP in those two ways. But I'd like to not guess but look at the packets to determine what the cause might be. Could you please post the wireshark pcap file to www.cloudshark.org and paste the link here in a comment? (Only if you are not revealing privacy sensitive information in the pcap file) answered 20 Jan '13, 01:53 SYN-bit ♦♦ Thank you for your comments. I tried to upload a pcap file that showing the problem but I don't know how to do. Could you show me how to upload a pcap file to www.cloudshark.org ? (29 Jan '13, 00:45) NewportMicro Open 'cloudshark.org' in your browser, click the button (large panel really) with the label "Drag and Drop a capture file to upload" and then a file browser dialog should open which allows you to choose a capture to upload. Post a link back to the uploaded capture file by editing your question, or adding a comment to an existing answer. (29 Jan '13, 01:40) grahamb ♦ |
Thank you. It is done. Below is the link :
http://www.cloudshark.org/captures/c4b78426649d
The IP of the Web server target is 192.168.33.242. The IP of the client web site is 192.168.32.109.
Thank you very much for taking a look at it.
I converted your “answer” to a comment as that’s how this site works, see the FAQ for more info.