TCP Stream Processing differently

I have a server sending me 50K HTTP response (text html). I am only
interested in data that can fit one ethernet frame (1500 bytes) in the
middle of the stream. As this is connected over a slower network
connection, I was interested in finding out anyway to either discard
the first so many frames/packets or not read the last so many
frames/packets (beyond the frame I am interested in).

Looking with ethereal, I see 35 or so frames to get the entire
response. It is taking roughly 600msec roundtrip to get the data. As
I care about perhaps 100 bytes of data somewhere in teh middle of the
stream, is there any way to make the download/processing any
intelligent:

1. Seems like I cannot forward the stream to the desired location w/o
reading it first - yes/no?
2. Can the kernel/device driver be tuned to discard the packets/frames
and not pass it to kernel (my application) for processing until the
desired packet is located/read? This would atleast shave some time off
wasted in processing unneeded packets/data?

This is a specialized computer only reading from a specific server - so
I do not mind tweaking anything/everything to save the time.

Any help and pointers are very much appreciated.

No such thing in HTTP that I am aware of - the server is creating
content dynamically anyways:

.....I thought that HTTP had ways to request data from specific offsets
in
a URL? If so, seems the best way to get just the data you want is to
ask for just the data you want in the first place ....

I get your point regarding network latency to be the bulk of where the
time is being spent so nothing on the client processing will give me
the meaningful added savings.

Can TCP packets be fudged that the server is tricked into sending the
packet I am ineterested in w/o sending the preceeding junk? Can I
manipulate the pointers in the TCP header to indicate the place in
stream where I would like it to be?

(E-Mail Removed) wrote:
> I have a server sending me 50K HTTP response (text html). I am only
> interested in data that can fit one ethernet frame (1500 bytes) in
> the middle of the stream. As this is connected over a slower
> network connection, I was interested in finding out anyway to either
> discard the first so many frames/packets or not read the last so
> many frames/packets (beyond the frame I am interested in).

If the network is slow, simply reading the bytes from the socket and
tossind them isn't going to add any extra wall clock time to the
process. The "damage" was done when the server was asked to transmit
all that unwated data at the beginning in the first place.

> Looking with ethereal, I see 35 or so frames to get the entire
> response. It is taking roughly 600msec roundtrip to get the data.
> As I care about perhaps 100 bytes of data somewhere in teh middle of
> the stream, is there any way to make the download/processing any
> intelligent:

> 1. Seems like I cannot forward the stream to the desired location w/o
> reading it first - yes/no?

No, there is no lseek for a TCP connection. At least not within TCP.
And again, in terms of how long it would take to get to the data, the
"damage" is already done if the server sends the unwanted data in the
first place - it will still take just as long for the wanted data to
get to you from behind the unwanted data.

> 2. Can the kernel/device driver be tuned to discard the packets/frames
> and not pass it to kernel (my application) for processing until the
> desired packet is located/read? This would atleast shave some time off
> wasted in processing unneeded packets/data?

> This is a specialized computer only reading from a specific server - so
> I do not mind tweaking anything/everything to save the time.

I thought that HTTP had ways to request data from specific offsets in
a URL? If so, seems the best way to get just the data you want is to
ask for just the data you want in the first place

rick jones
--
oxymoron n, Hummer H2 with California Save Our Coasts and Oceans plates
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

(E-Mail Removed) wrote:
> No such thing in HTTP that I am aware of - the server is creating
> content dynamically anyways:

A web search for "HTTP range" gave this as one of the top hits:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

The section that looks interesting is 14.35, which on the surface
looks like it does exactly what you want. Assuming of course your
client and server support it. My quick perusal seemed to suggest no
explicit limitations wrt dynamci content, but then it was a quick read
and I am by no means an HTTP expert, just someone with vague
recollections and a willingness to sound-off based on same

> I get your point regarding network latency to be the bulk of where

I'd probably call that network transit time - it may be related to
latency, it may be related to bandwidth.

> the time is being spent so nothing on the client processing will
> give me the meaningful added savings.

> Can TCP packets be fudged that the server is tricked into sending
> the packet I am ineterested in w/o sending the preceeding junk? Can
> I manipulate the pointers in the TCP header to indicate the place in
> stream where I would like it to be?

Nope.
TCP sends and receives a byte stream.
Period.

TCP's whole being is centered around getting all the bytes given it to
the other side, intact and in order, or die trying (and telling you
so). To try to convince TCP to only "really" send part of the data
would damage its psyche in a manner similar to what happened to HAL
and could result in similar consequences...

rick jones
--
firebug n, the idiot who tosses a lit cigarette out his car window
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...