Re: end of tcp stream .

Well today I understood that inside the TCP data I?m transferring there is
one filed indicating the size of the TCP data.

So I can check the first TCP frame and extract the size of the incoming
data,

Then just accumulate the rest of the incoming frames until all data arrives.



But what if I didn?t know the data size?

How come PUSH flag is not an indicator?



According to what you say there is no difference between TCP and UDP ?



Thank's .

Sharon



"Alexander Nickolov" <agnickolov@xxxxxxxx> wrote in message
news:OIV$8KslFHA.3380@xxxxxxxxxxxxxxxxxxxxxxx
> The TCP PSH flag is not used by modern TCP stacks. It's only
> being set for compatibility with ancient TCP implementations.
> Most likely reason a PSH flag is set is that the sender's send
> buffer was depleted. That has no relation whatsoever to any
> higher protocol message boundaries (if any).
>
> --
> =====================================
> Alexander Nickolov
> Microsoft MVP [VC], MCSD
> email: agnickolov@xxxxxxxx
> MVP VC FAQ: http://www.mvps.org/vcfaq
> =====================================
>
> "Sharon" <Sharon669@xxxxxxxxxxx> wrote in message
> news:%23lkHqhPlFHA.3316@xxxxxxxxxxxxxxxxxxxxxxx
>> Hi guys
>>
>> I uploaded 10 pictures of the sniffer output (commercial sniffer, not my
>> sniffer ...)
>>
>> http://planet.nana.co.il/develop/Sniffer/Sniff.htm
>>
>> In the 5 first pictures you can see the 5 frames I'm trying to assemble,
>> The PUSH flag is 0 in all frames except of the last one,
>> My sniffer works great with the software simulation program, because I'm
>> searching the PUSH flag.
>>
>>
>> dataFrame1 push=0
>> dataFrame2 push=0
>> AckFrame
>> dataFrame3 push=0
>> dataFrame4 push=0
>> AckFrame
>> dataFrame5 push=1
>>
>> the conditioning in the lab is different (next 5 pictures)
>> there is a UNIX station transmitting data ,
>> this is the same data size as the software simulation
>> but the difference is in the PUSH flag
>>
>> I get the push flag before ACK frame .
>>
>> dataFrame1 push=0
>> dataFrame2 push=1
>> AckFrame
>> dataFrame31 push=0
>> dataFrame41 push=1
>> AckFrame
>> dataFrame51 push=1
>>
>> so I don't know how to Assemble the data correctly
>>
>> Thank you for you helps
>> imp trying to process your replays .
>>
>> Sharon
>>
>>
>>
>>
>>
>>
>>
>> "Sharon" <Sharon669@xxxxxxxxxxx> wrote in message
>> news:OnOv7h2kFHA.3828@xxxxxxxxxxxxxxxxxxxxxxx
>>
>>> Hi all
>>>
>>> I'm a java/bv programmer sorry for my lack of Winsock knowledge (and
>>> lack
>>> of
>>> good English .)
>>>
>>>
>>>
>>> I had this task to implement a simple sniffer (C code using Winsock )
>>>
>>> searching the internet I found relatively simple code , and changed it
>>> successfully according to my needs .
>>>
>>>
>>>
>>> My problem is like that:
>>>
>>>
>>>
>>> I am monitoring data sent over the TCP protocol,
>>>
>>> The broadcasting station transmits different sizes of data, the problem
>>> I
>>> encountered was when sending 6000 bytes of data.
>>>
>>>
>>>
>>> This data is fragmented into 4 frames 1514 size each, between them I
>>> get
>>> ACK frames
>>>
>>> So I tried to count on the PUSH flag of TCP , but on the second frame -
>>> the
>>> PUSH flag is 1
>>>
>>>
>>>
>>> Professional sniffer shows something like :
>>>
>>>
>>>
>>> 1# frame 1514 PUSH = 0
>>>
>>> 2# frame 1514 PUSH = 1
>>>
>>> 3# frame 60 ACK
>>>
>>> 4# frame 60 ACK
>>>
>>> 5# frame 1514 PUSH = 0
>>>
>>> 6# frame 1514 PUSH = 1
>>>
>>> ..
>>>
>>>
>>>
>>>
>>>
>>> What I'm trying to understand is how do I know when is the end of the
>>> TCP
>>> data
>>>
>>> How do I know when to stop extracting data from the TCP frames and send
>>> the
>>> data to my host application (one level up)
>>>
>>>
>>>
>>> Thank you very much
>>>
>>> I will appreciate any help !
>>>
>>> Sharon
>>>
>>
>>
>>
>
>


.

Relevant Pages

  • Re: end of tcp stream .
    ... > Well today I understood that inside the TCP data I?m transferring there is ... > How come PUSH flag is not an indicator? ... >>> In the 5 first pictures you can see the 5 frames I'm trying to assemble, ... >>> AckFrame ...
    (microsoft.public.win32.programmer.networks)
  • RE: suffering from an apparently broken tcp
    ... suffering from an apparently broken tcp ... that outgoing packets had a checksum error at the TCP layer. ... Most of the time three TCP continuation frames come in back-to-back, ... it's only on the local network that's dreadfully slow. ...
    (Debian-User)
  • RE: suffering from an apparently broken tcp
    ... I'm really starting to convince myself that this is a hardware ... that outgoing packets had a checksum error at the TCP layer. ... Most of the time three TCP continuation frames come in back-to-back, ... it's only on the local network that's dreadfully slow. ...
    (Debian-User)
  • Re: Problem with writing fast UDP server
    ... it likely means you have reached your ethernet bandwidth ... frames) to achieve your desired results. ... Keep in mind TCP is stream based, not datagram based so you may need ... On your client, make the following changes. ...
    (comp.lang.python)
  • Re: end of tcp stream .
    ... The TCP PSH flag is not used by modern TCP stacks. ... > In the 5 first pictures you can see the 5 frames I'm trying to assemble, ... > The PUSH flag is 0 in all frames except of the last one, ...
    (microsoft.public.win32.programmer.networks)