tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <devli...@hanik.com>
Subject Re: comet client doesn't receive server response
Date Mon, 21 Jan 2008 19:49:42 GMT
the socket library itself shouldn't wait for protocol specific packets.
only if there is some sort of filtering mechanism on the box for the 
http protocol, then it would do it

Filip

Peter Warren wrote:
> But this client isn't using a proxy.  I've even tried the same client
> on my home network, where other machines function properly, to try to
> eliminate router/network/firewall issues.  Is it possible that (and
> here I'm delving into territory I know next to nothing about) the
> client's socket library waits until the response is closed?  It's a
> windows xp machine.
>
> On Jan 20, 2008 8:30 PM, Filip Hanik - Dev Lists <devlists@hanik.com> wrote:
>   
>> yes, most proxies will wait until they receive the end of the response,
>> before passing it on.
>> that's what you are seeing, a regular servlet, ends the response right away
>>
>> Filip
>>
>>
>> Peter Warren wrote:
>>     
>>> What is interesting to me is that the exact same client code only
>>> using a different url (i.e. to a normal http servlet, not a comet
>>> servlet) succeeds.  Is there something in comet response headers that
>>> an antivirus app or firewall would pick up on?  Why would a request to
>>> a normal servlet succeed and a comet servlet fail?  Keep in mind the
>>> comet servlet has been shown to be funtional on numerous other
>>> machines.
>>>
>>> I believe I disabled all firewalls and antivirus on the suspect
>>> machine, but I will double-check.
>>>
>>> Thanks for your response,
>>> Peter
>>>
>>> On Jan 15, 2008 9:37 AM, Leonardo Fraga
>>> <leonardo.fraga@cedrofinances.com.br> wrote:
>>>
>>>       
>>>> Hello,
>>>>
>>>> I've had problems with long http responses and some kind of antiviruses
>>>> and internet firewalls (avg family, basically).
>>>> They put a hook on the winsocket stack for http connections and buffer
>>>> everything you are receiving, until the end (or some high amount of
>>>> data), to run the checks. In my case, this buffering lasts for minutes,
>>>> with no byte sent back to the browser.
>>>>
>>>> I think this can be a simple point to check...
>>>>
>>>> Hugs,
>>>>
>>>> Leonardo Fraga
>>>> Web Developer
>>>> leonardo.fraga@cedrofinances.com.br
>>>>
>>>>
>>>> Peter Warren wrote:
>>>>
>>>>
>>>>         
>>>>> I posted this question along with some others recently.  I'm
>>>>> re-posting it in its own thread with some additional information.
>>>>>
>>>>> I have a comet client app that works on all the machines I've tested
>>>>> except one.  The failing machine sends a comet request to the server
>>>>> and then waits indefinitely for the response, even though the server
>>>>> has sent the response and flushed the buffer.  I'm trying to figure
>>>>> out why the client doesn't receive the response and would really
>>>>> appreciate any tips.
>>>>>
>>>>> Server is latest from 6.0.x trunk and using nio connector.
>>>>>
>>>>> Failing machine info:
>>>>> - runs windows xp
>>>>> - windows firewall is turned off
>>>>> - fails on multiple networks, so it doesn't seem to be a router or
>>>>> firewall issue
>>>>> - computer has no problem with other network access
>>>>> - same test code pointed at a non-comet servlet (simply changing the
>>>>> url) succeeds!!!
>>>>>
>>>>> I used a socket monitoring tool to see if the client machine receives
>>>>> the response at all.  It doesn't appear to.  Below are traces from a
>>>>> successful machine and the failing machine.  I'm not a sockets expert,
>>>>> so I don't really know what to look for, but the two things that stand
>>>>> out to me are:
>>>>> - failing machine uses localhost ip instead of its LAN ip (which is
>>>>> 192.168.1.102 according to ipconfig)
>>>>>  - succeeding machine uses LAN ip
>>>>>  - I don't understand why they're different
>>>>> - failing machine receives WSAEWOULDBLOCK error instead of server response
>>>>>
>>>>> I believe the WSAEWOULDBLOCK basically indicates that there's nothing
>>>>> on the socket to be read, which seems to indicate that the failing
>>>>> machine never receives the response at all.
>>>>>
>>>>> Is this a comet problem?  Is it a routing problem?  Anyone have any
>>>>> ideas for what the problem might be?  Any tips on what I should
>>>>> investigate next?
>>>>>
>>>>> Thanks,
>>>>> Peter
>>>>>
>>>>> SUCCEEDING MACHINE SOCKET TRACE
>>>>> =========================
>>>>> Connect ----------------------------------------------------
>>>>> Address:       66.241.85.247:80
>>>>> Return Value:  0
>>>>> Error Code:    0
>>>>>
>>>>> GetSockName ------------------------------------------------
>>>>> Address:       192.168.1.133:1104
>>>>> Return Value:  0
>>>>> Error Code:    0
>>>>>
>>>>> SetSockOpt -------------------------------------------------
>>>>> Level:         SOL_SOCKET
>>>>> Opt Name:      SO_KEEPALIVE
>>>>> Opt Len:       4
>>>>> Return Value:  0
>>>>> Error Code:    0
>>>>> 01 00 00 00                                             ....
>>>>>
>>>>> Send -------------------------------------------------------
>>>>> Address:       192.168.1.133:1104 => 66.241.85.247:80
>>>>> Flags:         0
>>>>> Return Value:  0
>>>>> Error Code:    0
>>>>> Data:
>>>>> POST /servlet/Receive HTTP/1.1
>>>>> Host: www.seekspeak.com
>>>>> User-Agent: SeekSpeak
>>>>> Connection: keep-alive
>>>>> Content-Type: text/plain
>>>>> Transfer-Encoding: chunked
>>>>>
>>>>> 2c
>>>>> source_chat_id=192.168.1.1%3A486547763981705
>>>>>
>>>>>
>>>>> Recv -------------------------------------------------------
>>>>> Address:       192.168.1.133:1104 =< 66.241.85.247:80
>>>>> Flags:         0
>>>>> Return Value:  0
>>>>> Error Code:    0
>>>>> Data:
>>>>> HTTP/1.1 200 OK
>>>>> Server: Apache-Coyote/1.1
>>>>> Set-Cookie: JSESSIONID=4618F4394D4924A5629628ED1CD2ADDE; Path=/
>>>>> Transfer-Encoding: chunked
>>>>> Date: Thu, 10 Jan 2008 07:55:05 GMT
>>>>>
>>>>> 49
>>>>> OK
>>>>> COMMAND
>>>>> INVITATION_ACCEPTED
>>>>> tutorial_client
>>>>> Invitation accepted...
>>>>>
>>>>>
>>>>> FAILING MACHINE SOCKET TRACE
>>>>> =====================
>>>>> Connect ----------------------------------------------------
>>>>> Address:       66.241.85.247:80
>>>>> Return Value:  0
>>>>> Error Code:    0
>>>>>
>>>>> GetSockName ------------------------------------------------
>>>>> Address:       127.0.0.1:2085
>>>>> Return Value:  0
>>>>> Error Code:    0
>>>>>
>>>>> SetSockOpt -------------------------------------------------
>>>>> Level:         SOL_SOCKET
>>>>> Opt Name:      SO_KEEPALIVE
>>>>> Opt Len:       4
>>>>> Return Value:  0
>>>>> Error Code:    0
>>>>> 01 00 00 00                                             ....
>>>>>
>>>>> Send -------------------------------------------------------
>>>>> Address:       127.0.0.1:2085 => 66.241.85.247:80
>>>>> Flags:         0
>>>>> Return Value:  0
>>>>> Error Code:    0
>>>>> Data:
>>>>> POST /servlet/Receive HTTP/1.1
>>>>> Host: www.seekspeak.com
>>>>> User-Agent: SeekSpeak
>>>>> Connection: keep-alive
>>>>> Content-Type: text/plain
>>>>> Transfer-Encoding: chunked
>>>>>
>>>>> 2c
>>>>> source_chat_id=192.168.1.1%3A485374421886120
>>>>>
>>>>>
>>>>> Select -----------------------------------------------------
>>>>> Return Value:  0
>>>>> Error Code:    0
>>>>>
>>>>> Recv -------------------------------------------------------
>>>>> Address:       127.0.0.1:2077 =< 66.241.85.247:80
>>>>> Flags:         0
>>>>> Return Value:  -1
>>>>> Error Code:    WSAEWOULDBLOCK
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To start a new topic, e-mail: users@tomcat.apache.org
>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>           
>>>> ---------------------------------------------------------------------
>>>> To start a new topic, e-mail: users@tomcat.apache.org
>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>>
>>>>
>>>>         
>>> ---------------------------------------------------------------------
>>> To start a new topic, e-mail: users@tomcat.apache.org
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>>
>>>
>>>       
>> ---------------------------------------------------------------------
>> To start a new topic, e-mail: users@tomcat.apache.org
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>>     
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
>   


---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message