[RESOLVED] jamming tcp data :)

[pannam]

hi all,
i have a client that connects to a remote server....there is something that i am not being able to understand.. some times when too many tcp packets arrive in a quick succession my client is not able to handle it..only the first few packets are handled and after that the client becomes slow.. what is the cause of it ? and how do i handle it ???

[alex_read]

Is this a programming related question??

A few things that spring to mind are that your client is receiving a huge download at the same time, is the target of a Denial of Service attack or that their Network Interface Card speed is lower than the rest of the network (runnin at 10/100 whereas the other computer sending and network itself are at gigabit speed). Would any of these be your issue?

[dilettante]

More likely this is a case of "the packet fallacy."

The Lame List see item number 20.

TCP data is presented as a fragmented stream, there are no "packets" in the sense of messages. People often naively assume SendData X will result in GetData X when it isn't so except when the computers are slow and the network very fast.

Sender:
XXXXXXXXXX
YYYYYYYYYY

Receiver:
XXXXXXXXXXYYYYY
YYYYY

There are no message boundaries because TCP is not a message oriented protocol. There are certainly no "packets" except at a low level that your program may as well ignore since it can't see them. TCP can delay, resend, etc. the actual packets under the covers as required.

To force messaging on top of TCP you have to add framing. This can be as simple as an "end of message" delimiter. The sender must send the framed data, and the receiver must accumulate received data and recognize complete frames for processing.

Sender:
XXXXXXXXXX@
YYYYYYYYYY@

Receiver:
XXXXXXXXXX@YYYYY  (process XXXXXXXXXX and hold YYYYY)
YYYYY@            (process YYYYYYYYYY)

If people would stop saying "packet" they'd be doing each other a huge favor.

[leinad31]

Analogy to food: your client is trying to chew everything rather than setting them aside to be eaten at its own pace. Design similar to store and forward architecture in SMS communications, which forwards when it can be done (e.g. bandwidth available) rather than trying to send everything at real-time even at peak hours. In your case, just receive what arrives and store it for processing at a later time or by another exe (remember, VB is not multi threaded).

[jmsrickland]

If people would stop saying "packet" they'd be doing each other a huge favor.

Couldn't have been said better!

The OP doesn't seem to pay attention to his replies since I have seen his threads many times and every one of them refer to his SendData and GetData as packets.

[DigiRev]

It's still okay to refer to bits of data as packets as that is how they are handled by your program at the application layer...so long as you know they are not 'packets' at the TCP layer, but a stream.

So with that said, I still refer to bits of data as packets as that is how they are usually treated in most client/server programs...

[jmsrickland]

Understand. However, that's how you and me and a few other's understand it but in the general sense packets are what dilettante described and should not be refered to as in the high level programming like VB since VB is not really dealing with packets but rather just data or fragmented stream data.

To my way of thinking, packets are what you see when you use a packet sniffer and of course VB (using the Winsock.ocx) cannot process packets in that sense.

[dilettante]

I don't care what people call 'em as long as it doesn't cost them time debugging programs they need to get working.

[jmsrickland]

I don't care either but the first time I saw his post and he refered to it as packets I thought he was actually talking about packets so I didn't reply because I don't know too much about them so this kind of goes along with what you are saying about costing them their time since I would have replied and tried to help but I didn't want to get into packets. Know what I mean?

[pannam]

i am sorry for creating such a mess as i unknowingly called tcp data as tcp packets .well, i got this idea from google as they reffered to each data that a packet sniffer could detect as packet ..for example login packet, room packet, hash packet,send message packet, group chat packet ..

http://www.devinsmith.net/articles/mig33/mig33.html#cli_commands

i am still confused at what to call them.. anywayz my question was ..i have a rich textbox that process's the incoming message data but sometimes when the message are too quick then its not able to process all the data some are just cut off ..what might be the cause for this ? and what should i keep in mind when coding for winsock1_dataArrival?

[leinad31]

Might as well post your code... in the meantime, please note that winsock data arrival (I'll assume for the meantime your using winsock) is placed in the call stack (last in, first out) hence is not processed like a queue (first in, first out).

[pannam]

this is an example of how i have been coding .the whole code is kind of long so, just cutting off unnecessary portion ..

Private Sub sock1_DataArrival(ByVal bytesTotal As Long)
dim hash as string,strHeader as string
sock1.GetData dat, vbString, bytesTotal
hash = Replace(dat, vbNullChar, " ")
strHeader = Left(dat, 3) 
Select Case strHeader
Case Is = HextoAscii("02 00 C9")
'''''code to process this data''''''
txtascii= txtascii & vbcrlf & 'processed data'
end select
end sub

my problem is when ever i receive a lot of tcp data in quick succession that start with "02 00 C9" my code is not being able to process all of it ,only a few tcp data are processed and rest are omitted ..one more information the 9th byte determines the length of the tcp data from that point till the end ...

[leinad31]

Long streams of data are divided into chunks or several data arrivals... so only first chunk of long stream will contain header and be processed, the rest will be ignored.

If each stream is transmitted on one connection that is closed when send is over then concatenate bytes in data arrivals and process when connection is closed (or stream is completed).

[DigiRev]

You need to store all received data into a buffer. Then process the buffer one 'packet' at a time.

The length of the packet should be in the header. I remember telling you this in another one or two of your threads.

[pannam]

You need to store all received data into a buffer. Then process the buffer one 'packet' at a time.

The length of the packet should be in the header. I remember telling you this in another one or two of your threads.

allrite , thank you . i thought it was a different sort of error..okay i will do as told