Underlying TCP stats

[Tractatus]

Chaps

I'm after the number of TCP packets for a given session's request and
in a response.

I'd prefer not to estimate by summing bytes in headers and responses
in case max segment size isn't the default 1460...

Any ideas for a newbie?

Best regards

Neil

[EricLaw]

You need to use NetMon (http://www.fiddler2.com/redir/?id=netmon) for
a task like this, although such a practice usually is a waste of time
unless you happen to be an ops-engineer with the ability to tune TCP/
IP settings.

For web developers and others, your best bet is to simply use Fiddler
to improve caching, enable compression, reduce redundant requests, and
shrink response size.

-Eric

[Tractatus]

Thanks for the quick reply Eric,

I was hoping to use a friendly tool like your Fiddler (which everyone
knows, likes and understands), rather than a TCP level sniffer. I
want to get the javascipt guys to routinely check whether their
minified, compressed files just drop a few bytes into an extra packet
- and then try that bit harder to shrink their files if they do.

Ditto, the image guys.

We're over some very lossy networks.

Thanks anyway

Neil

[EricLaw]

But a spot measurement is really not going to tell you anything
interesting, unless ALL of your TCP/IP packets happen to always be the
same size.

And if you're willing to assume that they are for some reason, you
could just as easily divide the Fiddler-calculated response size by
the packet size and you're done.

> > > Neil- Hide quoted text -
>
> - Show quoted text -

[Tractatus]

Hi Eric

this is getting a bit out of hand.

By testing using spoofed lossy networks, I reckon that by getting the
90% of a certain kind of resource down to 1 TCP packet rather than 2
that I can reduce overall download time for a key page by about 50 -
60%.

I need a quick way that I, and more importantly my colleagues who
maintain this stuff (and who run Fiddler all day every day), can
easily keep an eye on # packets for the various resources.

I can pcap this stuff as you suggest, but I don't expect my colleagues
to.

So 2 questions if I may - if you still think that what I'm trying to
achieve is foolish then could we discuss that separately?

- Is there a way of exposing the TCP stuff through so that people like
me who think they want it can use it?

- and would you be prepared to expose this stuff in a later release?

Best regards

N

[EricLaw]

I'm not sure what you mean when you say "getting out of hand".

>could we discuss that separately

Separately from what?

What you're asking for fundamentally doesn't make sense. Either you're
willing to assume all TCP/IP packets are the same size (for the sake
of simplicity) or you're not. If you are, just use Fiddler and divide
the response size by the packet size. If you're not, then a spot
measurement from one location is basically irrelevant and cannot
reliably be generalized out to the population as a whole.

> - Is there a way of exposing the TCP stuff through so that people like
> me who think they want it can use it?

No. The "TCP/IP stuff" (aka raw packets) are reassembled by the
operating system *before* the socket is read. The underlying
information is not available to the user (in this case, Fiddler) of
the socket.

> > > - Show quoted text -- Hide quoted text -