ponley has asked for the wisdom of the Perl Monks concerning the following question:

I'm trying to watch some network traffic using Sniffer::HTTP. for the most part it is working well for me however on some of the larger connections I will see the message

Need more response body data (some%)

It will count up to 98%-100% and then timeout and the connection is deleted and all the data lost. My guess from looking at the code is that a packet somewhere in the middle got lost so length ($$buffer) is never going to be > $len. Problem is I can't for the life of me find a way to access the data that was captured and write it out so that I can look at it compared to what should have been captured and track down the which is the errant packet and figure out why it is being missed.

Can anyone help me to access the data that was captured upto the time of the stale_connection callback?

Thank you

Replies are listed 'Best First'.
Re: Sniffer::HTTP problem with timeout
by Corion (Patriarch) on Mar 20, 2011 at 07:06 UTC

    The ->recv_buffer holds the data that was captured. So in your stale_connection callback, you can use it to retrieve what was received so far.

      Thanks for the quick reply. That's what I had thought. I have this for the stale_connection callback.
      stale_connection => sub { my ($s,$conn,$key) = @_; print "Stale Connection\n".${$conn->recv_buffer}."\n"; $conn->log->("$key is stale."); $s->remove_connection($key); },
      and all I get is a blank line following the Stale Connection text. After reading your response I went into Sniffer/Connection/HTTP.pm and added
      print ${$self->recv_buffer};
      which does print the data. So somehow I seem to be losing the data on the way back to my code. What am I doing wrong?

        If the ->recv_buffer is empty, then the payload got already moved up to ->_response, at least that's what I read from my code in ->flush_received. I'm not sure how useful the data will be, but at least if you want to issue a second request using a Range: to resume downloading the data, it might be helpfull.