Re: end of tcp stream .

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

Oops, mea culpa , word "tcp" gone somehow ...
Arkady

"Roger Hunen" <rhunen@xxxxxxxxx> wrote in message
news:O6CsCk5kFHA.3828@xxxxxxxxxxxxxxxxxxxxxxx
> Sorry to say, but Arkady's reply does not lead anywhere near to a solution
> for the OP's problem. The DF/MF bits have nothing to do with it: these
> deal
> with IP-level fragmentation which will not happen in a normal TCP stream.
>
> The big problem here is that TCP has no concept of message boundaries:
> TCP is about octet streams. What the OP wants to achieve may therefore
> be easy or difficult depending on the situation. Let's have a look at a
> few:
>
> 1. The sender opens a TCP connection, sends the data and closes
> the connection.
>
> In this situation the end of the data is marked by a TCP segment with
> the FIN bit set. This is an easy one.
>
> 2. The sender opens a TCP connection, sends data, waits for a response
> from the receiver, sends more data, waits for another response, etc.
>
> In this situation packets with data from the sender are interleaved with
> packets containing response data from the receiver. Analyzing this data
> pattern is a common way to dissect unknown client-server data streams.
>
> Unfortunately this only works if the clients does not send another
> request
> to the server until it has received a response to the first request.
>
> 3. The sender opens a TCP connection, sens data, sends more data without
> waiting for a response from the other end, etc. or may send multiple
> (overlapped) request to the server before it has to wait for a response.
>
> In this situation you have no clue about the message boundaries unless
> you
> have knowledge about the communication protocol. Good generic sniffer
> programs have analyzer modules for many common application protocols.
>
> Regards,
> -Roger
>
>
> "Arkady Frenkel" <arkadyf@xxxxxxxxxxxxxxxx> wrote in message
> news:uekdJf4kFHA.1608@xxxxxxxxxxxxxxxxxxxxxxx
>> Look at controls flags ( DF/MF ) in
>> http://www.faqs.org/rfcs/rfc791.html
>> Arkady
>>
>> "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: Socket weirdness
    ... It's hard to explain all of TCP in a single post. ... then that is an not a valid packet and a packet with the RST bit set is sent clearing down the connection. ... Firstly, just to be absolutely clear, there is no such thing as an ACK packet, or a RST packet, or a SYN packet, etc. ... I was leading in to my next question about whether Send blocked for that response because I assumed ...
    (microsoft.public.dotnet.framework)
  • Re: end of tcp stream .
    ... with IP-level fragmentation which will not happen in a normal TCP stream. ... The sender opens a TCP connection, sends data, waits for a response ... >> This data is fragmented into 4 frames 1514 size each, ...
    (microsoft.public.win32.programmer.networks)
  • Re: TCP server does not detect the client network failure
    ... > generate a response, ... It's layers on layers. ... and think what is required of TCP (none of the layers below TCP do ... it assumes the connection is broken. ...
    (comp.lang.java.programmer)
  • Re: Guaranteed to annoy people further... What makes a packet x big?
    ... Those packets can be as big as the MTU size allows. ... TCP further breaks up the data it has to send ... There is a trade-off between better interactive response and bandwidth ...
    (uk.comp.sys.mac)
  • Re: IP Tables problem
    ... When the resolver issues a query and the response comes back with the TC ... resolver normally issues the request again, using TCP. ... >transfer type use, and UDP for queries. ...
    (RedHat)