Fast TCPSend and packet aggregation

[Apzo]

Hello

TCPRecv will try to read maxlen chars from a connection (see the help file).

But If I use 2 TCPSend with short datas (length of the two packets < maxlen), datas will be agregated and it's a bit disturbing.

More, if length(packet1) + length(packet2) > maxlen, I may receive one maxlen packet containing packet1 and a part of packet2, then a second packet with the remaining datas from packet2.

Is there any option (system or AU3) to prevent packet aggregation ?

If not, 3 "solutions :

1) postfix each sent packet with a unique sequence, telling the listerner how to split the received datas.

Received datas should be added to a FIFO buffer then read when at least a complete message is in.

You would need a buffer per socket.

Works in all cases, but that's a bunch of code.

2) Add a sleeping time just after the TCPSend.

Ugly, makes everything slower, but works.

3) Fill incomplete packets with dummy chars up to maxlen.

Dirty, but works too.

"solutions" 2) and 3) can't work with packet over maxlen length.

Some of you may have got the same problem, your feedback would be appreciated

Apzo.

[Apzo]

I'll try to make it shorter..

Client side :

TCPSend($socket, "Packet 1")
TCPSend($socket, "Packet 2")oÝ÷ Ù'«½êì׺Ú"µÍÌÍÑ]HHÔXÝ  ÌÍÛÝ[ÜÛØÚÙ]
LLBÛÛÛÛUÜ]J    ][ÝÉÝÈ  ][ÝÈ  [È ÌÍÑ]H    [ÈoÝ÷ ÚOiÉ·SÚrG­Ù8^±©{¦¦W°Ølç©çM~׫¶µ²ÔÂ='§vOiÉ·X-=§$zÝ笱0IéÝ¢´Â=¾+.²)ài»}êÚÛkÊÚ
Þ«^¥§$zÛ"~,²&åxb²z-jz'±éìyúèØ^L#é¢)í¡ûâ{î¶÷«É©ç£(§úèØ^uëÞ^¯l¢w¥¶[@rÛ­+"²0"Ê%½çm+'§µ(y«­¢+ØÀÌØí=@ô
¡È Ȥ)Q
AM¹ ÀÌØíͽ­Ð°ÅÕ½ÐíA­ÐÄÅÕ½ÐìµÀìÀÌØí=@¤)Q
AM¹ ÀÌØíͽ­Ð°ÅÕ½ÐíA­ÐÈÅÕ½ÐìµÀìÀÌØí=@oÝ÷ Ù'«½êì׺Ú"µÍÌÍÑSÔHÚBÌÍÕXÚÈHÜ   ÌÍÕXÚÈHÈ  ÌÍÓX^ÛÛXÝ[ÛRY    ÌÍÐÛÛXÝYÛØÚÙ]ÉÌÍÕXÚ×H   ÉÝÈHH[BIÌÍÑQÐYÉÌÍÕXÚ×H [ÏHÔXÝ   ÌÍÐÛÛXÝYÛØÚÙ]ÉÌÍÕXÚ×K   ÌÍÓX^[Ý
HÙ[ÈHÝ[ÈYBUÚ[H
Ý[Ò[Ý    ÌÍÑQÐYÉÌÍÕXÚ×K    ÌÍÑSÔJJHÝHYÛÛZ[È]XÝÛHÛÛ]HYÜØYÙBBBSØØ[  ÌÍÔHÝ[Ò[Ý ÌÍÑQÐYÉÌÍÕXÚ×K    ÌÍÑSÔ
BBBIÌÍÑ]HHÝ[ÓY
    ÌÍÑQÐYÉÌÍÕXÚ×K    ÌÍÔLJHÝHYYÜHÚBBBIÌÍÑQÐYÉÌÍÕXÚ×HHÝ[Õ[SY
    ÌÍÑQÐYÉÌÍÕXÚ×K    ÌÍÔ
ÌJHÜ[[ÝHHYÜØYÙH[]ÈÙ]ÜBBNÈ^HÝYÚ] ÌÍÑ]HBBUÑ[Q[Y^

$FIFOBuffer is a string array, one string per socket.

TCPRecv fills the buffer of the receiving socket, then a While ... WHend tries to empty it.

This way, if the buffer contains an "unfinished" message, this message would be completed next time.

I did this after my first post, and it works fine

The maxlen parameter from TCPRecv is no more a problem, and the sent packets can now have any length (greater or lower than maxlen), I will always have my complete message.

Apzo.

[SkinnyWhiteGuy]

I thought that was the solution, but I was waiting to say anything, hoping there was some kind of nifty solution. Now that I've got an answer for sure, I have a new question: when you say you define the data, do you mean your header starts with a specific sequence, or just like the file name, if your transferring a file, or something else? This is more of a "what's the best way to" instead of "how do you" type question.

[Apzo]

I thought that was the solution, but I was waiting to say anything, hoping there was some kind of nifty solution. Now that I've got an answer for sure, I have a new question: when you say you define the data, do you mean your header starts with a specific sequence, or just like the file name, if your transferring a file, or something else? This is more of a "what's the best way to" instead of "how do you" type question.

Basically a message is built this way : "header:datas" where ":" is a separator.

No need to know how your header starts, because it is the begenning of the sent message.

Instead, you have to know where it ends !

You may use a sequence to end your header, then StringSplit your message with this sequence to isolate both headers and datas. Simple, efficient.

The header too can be splitted with (another !) sequence. This is mostly the case.

Example of header : "data_type|data_length|extra_params..."

where data_type would be $file or $talk, data_length is there to check data integrity, and extra_param for a filename or whatever.

Better, the number of header fields can vary depending on the data_type you have.

You will find some header and message samples in the IRC RFC (beware, IRC header specs are rather messy).

Just to see how they did it, it's interesting.

Apzo.

[SkinnyWhiteGuy]

Well, what I was thinking about doing (when I get around to playing with all this) is making a static header size, that it tried to read first, that then setup the actual data transfer for the appropriate amount based on what the header says. Simple and should work. Only problem is trying to determine just how big to make the static header, without shooting yourself in the foot. I was just wondering if anyone else had that idea, or reasons why it wouldn't work out well.

[Fabry]

you can define the time before TCP functions stop if no communication.

Time in milliseconds before timeout (default=100). OPT(tcptimeout,$value). Second solution.