We will try Wireshark. BTW, the inherent linux sniffer, tcpdump, is pretty advanced and we used its filtering feature to pin point this packet reduction. However, the disruption seems to occur somewhere lower level in the server OS, or more likely before the server machine altogether - some network equipment or client side code / browser.
Thanks again for your help. Amit On Dec 2, 12:05 pm, Lothar Kimmeringer <[EMAIL PROTECTED]> wrote: > Amit Kasher schrieb: > > > I have been trying tcpdump sniffer in the server side, and discovered > > that the server always receives 80% of the byte content (I described > > it here:http://tinyurl.com/5rqfp5). This is very interesting, but > > unfortunately led me nowhere. > > I just read the first post (shame on me ;-) but I still think > that Wireshark might help here. When the problem occurs, you can > simply reduce the view of the packets to the one session by > simply applying a filter on it. That way it should be possible > to see what was happening _before_ the packets got reduced. > > > I don't manage to reproduce it, for over a year now, so I can't run a > > sniffer in the client. Also, this is a high capacity internet > > application, not intranet, therefore contacting the users even just > > for a question is rather difficult, let alone installing a sniffer in > > the client side. > > The sniffer on the client-side would be a next step to be > considered. In the first place I think that it should be > enough to have one on the server-side (listening only to > HTTP-traffic). > > Regards, Lothar --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
