Can I send directly everytime I call the client.Send(@sf, sizeof(sf))?
Does TWSocketServer have any property that allow me to send everything
without buffered first?
regards,
Widita

Can I send directly everytime I call the client.Send(@sf, sizeof(sf))?

Yes, but pay attention to dynamic data which is represented by pointers.
Sending a pointer to a remote site is useless !
Dynamic data are long strings, objects, dynamic arrays, pointer to
anything,

Does TWSocketServer have any property that allow me to send everything

You never send anything with TWSocketServer. When you send something it is
thru one of the TWSocketClient instanciated by TWSocketServer to handle
client connection (you have access to all those sockets thru
TWSocketServer.Client[].

to send everything without buffered first?

What do you mean by "buffering first" ?

Contribute to the SSL Effort. Visit

2/19/06, Francois PIETTE <francois.piette (AT) overbyte (DOT) bewrote:

Can I send directly everytime I call the client.Send(@sf, sizeof(sf))?

Yes, but pay attention to dynamic data which is represented by pointers.
Sending a pointer to a remote site is useless !
Dynamic data are long strings, objects, dynamic arrays, pointer to
anything,

Does TWSocketServer have any property that allow me to send everything

You never send anything with TWSocketServer. When you send something it is
thru one of the TWSocketClient instanciated by TWSocketServer to handle
client connection (you have access to all those sockets thru
TWSocketServer.Client[].

Yes, I used Client.Send

to send everything without buffered first?

What do you mean by "buffering first" ?

It's something like this, when I send 2 packets consecutively, 1 after
another, it often received as one packet in the client side
(WSocket1DataAvailable event)

After I read the help files, I found this:

Declaration
Function Send(Data : Pointer; Len : Integer): integer;

Description
Send arbitrary data thru the socket. Data is given by address and size. Data
is placed in a buffer for sending in the background. This buffer is
allocated dynamically so it seems to be huge. But be aware that it consume
free memory on the heap.

Contribute to the SSL Effort. Visit

to send everything without buffered first?

>What do you mean by "buffering first" ?

It's something like this, when I send 2 packets consecutively, 1 after
another, it often received as one packet in the client side
(WSocket1DataAvailable event)

This is how TCP stream is operating. In technical words, "datagram
boundaries are not preserved". You can't change anything to that: it's not a
component issue but simply how TCP protocol has been designed. See "TCP/UDP
primer" document available from the support page at my website for more
details.

Contribute to the SSL Effort. Visit

2/19/06, Francois PIETTE <francois.piette (AT) overbyte (DOT) bewrote:

to send everything without buffered first?
>
>What do you mean by "buffering first" ?
>
It's something like this, when I send 2 packets consecutively, 1 after
another, it often received as one packet in the client side
(WSocket1DataAvailable event)

This is how TCP stream is operating. In technical words, "datagram
boundaries are not preserved". You can't change anything to that: it's not
a
component issue but simply how TCP protocol has been designed. See
"TCP/UDP
primer" document available from the support page at my website for more
details.

, then I must manage the received buffer by myself?
cutting and joining so that it can be interpreted perfectly by the receiver,
is that right?

, then I must manage the received buffer by myself?
cutting and joining so that it can be interpreted perfectly by the
receiver,
is that right?

Yes and no :-)
TWSocket has a "line mode" in which it assemble (or split) packets for you.
You specify a delimiter (default to #13#10 but can be anything), tunr line
mode on and then you get DataAvailable triggered only when one complete
line (well anything terminated by your delimiter) has been received. If a
line is split in several packets, or a single packet contain several lines,
TWSocket will always trigger exactly one DataAvailable per line received.

If you don't use line mode, then you must design your protocol the way you
like. Basically, your receiver has to know what the sender is sending ! If
not using a delimiter (line mode), then you either have to send fixed length
record, or send somewhere the length or the type of your record (probably at
the start of the record).

Contribute to the SSL Effort. Visit

Message
From: "Surabaya" <babatan (AT) gmail (DOT) com>
To: "ICS support mailing" <twsocket (AT) elists (DOT) org>
Sent: Sunday, February 19, 2006 5:54 PM
Subject: Re: [twsocket] Sending directly, not via Send Buffer

2/19/06, Francois PIETTE <francois.piette (AT) overbyte (DOT) bewrote:
>>
>to send everything without buffered first?
>>
>>What do you mean by "buffering first" ?
>>
>It's something like this, when I send 2 packets consecutively, 1 after
>another, it often received as one packet in the client side
>(WSocket1DataAvailable event)
>>
>This is how TCP stream is operating. In technical words, "datagram
>boundaries are not preserved". You can't change anything to that: it's
>not
>a
>component issue but simply how TCP protocol has been designed. See
>"TCP/UDP
>primer" document available from the support page at my website for more
>details.
>>
>
, then I must manage the received buffer by myself?
cutting and joining so that it can be interpreted perfectly by the
receiver,
is that right?

I wonder why you are trying to reinvent the wheel? What is that ICS cannot
do?

Regards,

SZ

2/19/06, Francois PIETTE <francois.piette (AT) overbyte (DOT) bewrote:

, then I must manage the received buffer by myself?
cutting and joining so that it can be interpreted perfectly by the
receiver,
is that right?

Yes and no :-)
TWSocket has a "line mode" in which it assemble (or split) packets for
you.
You specify a delimiter (default to #13#10 but can be anything), tunr line
mode on and then you get DataAvailable triggered only when one complete
line (well anything terminated by your delimiter) has been received. If a
line is split in several packets, or a single packet contain several
lines,
TWSocket will always trigger exactly one DataAvailable per line
received.

Nah, this is what I need how long can the delimiter be? can it be 5
characters?

If you don't use line mode, then you must design your protocol the way you
like. Basically, your receiver has to know what the sender is sending ! If
not using a delimiter (line mode), then you either have to send fixed
length
record, or send somewhere the length or the type of your record (probably
at
the start of the record).

It will be much better I can use the line mode

I'm going to send binary data, using 5 characters delimiter is it safe?

Contribute to the SSL Effort. Visit

Hello Surabaya,

if you send binary with LineMode there are many way to manage it.

The simplest : use BASE64 e-mail attachement style that is nice as
designed to work ascii lined mode but increase size of data about
+40% (as all binary e-mail attachements do by the way).

You could also send binary but then you should take care to backslash
all delimiter characters/bytes.

You can also temporary switch between lined mode and binary mode : if
line mode N and receive string "bin 1223435" then LineMode FF and
receive data until size = 1223435 then LineMode N again.

Regards.

S2/19/06, Francois PIETTE <francois.piette (AT) overbyte (DOT) bewrote:
>>
>, then I must manage the received buffer by myself?
>cutting and joining so that it can be interpreted perfectly by the
>receiver,
>is that right?
>>
>Yes and no :-)
>TWSocket has a "line mode" in which it assemble (or split) packets for
>you.
>You specify a delimiter (default to #13#10 but can be anything), tunr line
>mode on and then you get DataAvailable triggered only when one complete
>line (well anything terminated by your delimiter) has been received. If a
>line is split in several packets, or a single packet contain several
>lines,
>TWSocket will always trigger exactly one DataAvailable per line
>received.

SNah, this is what I need how long can the delimiter be? can it be 5
Scharacters?

SIf you don't use line mode, then you must design your protocol the way you
>like. Basically, your receiver has to know what the sender is sending ! If
>not using a delimiter (line mode), then you either have to send fixed
>length
>record, or send somewhere the length or the type of your record (probably
>at
>the start of the record).

SIt will be much better I can use the line mode

SI'm going to send binary data, using 5 characters delimiter is it safe?

SContribute to the SSL Effort. Visit
>--
>francois.piette (AT) overbyte (DOT) be
>http://www.overbyte.be
>>
>>
>--
>To unsubscribe or change your settings for TWSocket mailing list
>please goto
>Visit our website at http://www.overbyte.be
>>

I'm going to send binary data, using 5 characters delimiter is it safe?
Yes, provided your delimiter is not within the data !
If data must contain the delimiter, then you have to escape it.

K, I'll try the Base64 method

Do you have any recommendation about Base64 encoding/decoding library?

2/19/06, Dod <dodfr (AT) sky (DOT) frwrote:

Hello Surabaya,

if you send binary with LineMode there are many way to manage it.

The simplest : use BASE64 e-mail attachement style that is nice as
designed to work ascii lined mode but increase size of data about
+40% (as all binary e-mail attachements do by the way).

You could also send binary but then you should take care to backslash
all delimiter characters/bytes.

You can also temporary switch between lined mode and binary mode : if
line mode N and receive string "bin 1223435" then LineMode FF and
receive data until size = 1223435 then LineMode N again.

Regards.

What about Mimeutils.pas in ICS package?

Regards,

SZ

Message
From: "Surabaya" <babatan (AT) gmail (DOT) com>
To: "ICS support mailing" <twsocket (AT) elists (DOT) org>
Sent: Sunday, February 19, 2006 7:42 PM
Subject: Re: [twsocket] Sending directly, not via Send Buffer

K, I'll try the Base64 method

Do you have any recommendation about Base64 encoding/decoding library?

2/19/06, Dod <dodfr (AT) sky (DOT) frwrote:
>>
>Hello Surabaya,
>>
>if you send binary with LineMode there are many way to manage it.
>>
>The simplest : use BASE64 e-mail attachement style that is nice as
>designed to work ascii lined mode but increase size of data about
>+40% (as all binary e-mail attachements do by the way).
>>
>You could also send binary but then you should take care to backslash
>all delimiter characters/bytes.
>>
>You can also temporary switch between lined mode and binary mode : if
>line mode N and receive string "bin 1223435" then LineMode FF and
>receive data until size = 1223435 then LineMode N again.
>>
>Regards.
>>

, I'll try it thanks

2/20/06, Fastream Technologies <gates (AT) fastream (DOT) comwrote:

What about Mimeutils.pas in ICS package?

Regards,

SZ

Message
From: "Surabaya" <babatan (AT) gmail (DOT) com>
To: "ICS support mailing" <twsocket (AT) elists (DOT) org>
Sent: Sunday, February 19, 2006 7:42 PM
Subject: Re: [twsocket] Sending directly, not via Send Buffer
--
K, I'll try the Base64 method

Do you have any recommendation about Base64 encoding/decoding library?
>
>
>
2/19/06, Dod <dodfr (AT) sky (DOT) frwrote:
>>
>Hello Surabaya,
>>
>if you send binary with LineMode there are many way to manage it.
>>
>The simplest : use BASE64 e-mail attachement style that is nice as
>designed to work ascii lined mode but increase size of data about
>+40% (as all binary e-mail attachements do by the way).
>>
>You could also send binary but then you should take care to backslash
>all delimiter characters/bytes.
>>
>You can also temporary switch between lined mode and binary mode : if
>line mode N and receive string "bin 1223435" then LineMode FF and
>receive data until size = 1223435 then LineMode N again.
>>
>Regards.
>>

K, I'll try the Base64 method

It is more efficient to use a simple escape mechanism.
Let's say your delimiter is #13#10 (this is handy if you test with telnet).
The select another character which is likely to be infrequently use in your
binary data. Let's assume it is #127.
Then it is enough to scan all you binary data, check for #13, #10 or #127
characters and replace them by - respectively - #127 'M', #127 'J' and #127
'/' (or any other couple you like).
The nul char is also frequently escaped. Si replace #0 by #127 '0'.
At the other side, just do the reverse: scan data to find #127, then examine
next character to know which one to use instead of the pair which is the
'escaped value'.

Message
From: "Francois PIETTE" <francois.piette (AT) overbyte (DOT) be>
To: "ICS support mailing" <twsocket (AT) elists (DOT) org>
Sent: Sunday, February 19, 2006 3:57 PM
Subject: Re: [twsocket] Sending directly, not via Send Buffer


>, then I must manage the received buffer by myself?
>cutting and joining so that it can be interpreted perfectly by the
>receiver,
>is that right?
>
Yes and no :-)
TWSocket has a "line mode" in which it assemble (or split) packets for
you.
You specify a delimiter (default to #13#10 but can be anything), tunr line
mode on and then you get DataAvailable triggered only when one complete
line (well anything terminated by your delimiter) has been received. If a
line is split in several packets, or a single packet contain several
lines,
WSocket will always trigger exactly one DataAvailable per line received.

Is this completely true. I'm sure in the past I've had a receive call
return multiple lines, something like "This is one line'#13#10'this is the
next'#13#10'". And I had to split multiple lines, and process individually.
I don't know if this is a bug that was once fixed, but I remember having to
do it when I first started using TWSocket (years ago), and have done ever
since.

Dan

If you don't use line mode, then you must design your protocol the way you
like. Basically, your receiver has to know what the sender is sending ! If
not using a delimiter (line mode), then you either have to send fixed
length
record, or send somewhere the length or the type of your record (probably
at
the start of the record).

Contribute to the SSL Effort. Visit

Yes, right now I am facing the same problem as Dan's

I'm receiving more than one line in a call of DataAvailable
does TWSocket has any property to set so that there will only be a line per
DataAvailable event triggered?

2/20/06, Dan <Dan_F (AT) blueyonder (DOT) co.ukwrote:
--
Message
From: "Francois PIETTE" <francois.piette (AT) overbyte (DOT) be>
To: "ICS support mailing" <twsocket (AT) elists (DOT) org>
Sent: Sunday, February 19, 2006 3:57 PM
Subject: Re: [twsocket] Sending directly, not via Send Buffer
>
>
>, then I must manage the received buffer by myself?
>cutting and joining so that it can be interpreted perfectly by the
>receiver,
>is that right?
>
Yes and no :-)
TWSocket has a "line mode" in which it assemble (or split) packets for
you.
You specify a delimiter (default to #13#10 but can be anything), tunr
line
mode on and then you get DataAvailable triggered only when one
complete
line (well anything terminated by your delimiter) has been received. If
a
line is split in several packets, or a single packet contain several
lines,
WSocket will always trigger exactly one DataAvailable per line
received.

Is this completely true. I'm sure in the past I've had a receive call
return multiple lines, something like "This is one line'#13#10'this is the
next'#13#10'". And I had to split multiple lines, and process
individually.
I don't know if this is a bug that was once fixed, but I remember having
to
do it when I first started using TWSocket (years ago), and have done ever
since.
--

Yes, right now I am facing the same problem as Dan's

I'm receiving more than one line in a call of DataAvailable
does TWSocket has any property to set so that there will only be a line per
DataAvailable event triggered?

Set :
WSocket1.LineMode := TRUE;
WSocket1.LineEnd := #13#10; // whatever you need

Note that calling the message pump from an event handler will mess all things.

WSocket will always trigger exactly one DataAvailable per line received.

Is this completely true. I'm sure in the past I've had a receive call
return multiple lines, something like "This is one line'#13#10'this is the
next'#13#10'". And I had to split multiple lines, and process individually.
I don't know if this is a bug that was once fixed, but I remember having to
do it when I first started using TWSocket (years ago), and have done ever
since.

You must set LineMode := TRUE to have TWSocket handle receiving lines, and set LineEnd := #13#10;

Hello Francois,

And of course do not forget to escape the escape sequence itself if it
is already present in your original data.

You could also do a two-pass sending, first one send a position table
of delimiters located in your data, other send binary data with
delimiter replaced with #0. received you simply refill the #0#0
according to position table.

To give an idea, I counted #13#10 in different kind of files and a
47MB installshield EXE contained 1521 sequences, a 15.8MB TIFF
contained 300, a 4.3MB PDF contained 170, a unknown 8.4MB .DAT file
contained 294.

So if you send a first ascii position table in HEX 8 DWRD records it
would just add less than 10KB of data to total sending for 50MB.

regards.

>K, I'll try the Base64 method

FPIt is more efficient to use a simple escape mechanism.
FPLet's say your delimiter is #13#10 (this is handy if you test with telnet).
FPThe select another character which is likely to be infrequently use in your
FPbinary data. Let's assume it is #127.
FPThen it is enough to scan all you binary data, check for #13, #10 or #127
FPcharacters and replace them by - respectively - #127 'M', #127 'J' and #127
FP'/' (or any other couple you like).
FPThe nul char is also frequently escaped. Si replace #0 by #127 '0'.
FPAt the other side, just do the reverse: scan data to find #127, then examine
FPnext character to know which one to use instead of the pair which is the
FP'escaped value'.

FP--
FPfrancois.piette (AT) overbyte (DOT) be
FPhttp://www.overbyte.be

What do you mean about this statement?
"calling the message pump from an event handler"

what is message pump?

thanks

2/20/06, Francois Piette <francois.piette (AT) overbyte (DOT) bewrote:

Yes, right now I am facing the same problem as Dan's

I'm receiving more than one line in a call of DataAvailable
does TWSocket has any property to set so that there will only be a line
per
DataAvailable event triggered?

Set :
WSocket1.LineMode := TRUE;
WSocket1.LineEnd := #13#10; // whatever you need

Note that calling the message pump from an event handler will mess all
things.

Surabaya wrote:
What do you mean about this statement?
"calling the message pump from an event handler"

what is message pump?

For instance Application.ProcessMessages or anything else that
processes messages.

Arno

thanks

2/20/06, Francois Piette <francois.piette (AT) overbyte (DOT) bewrote:

Yes, right now I am facing the same problem as Dan's

I'm receiving more than one line in a call of DataAvailable
does TWSocket has any property to set so that there will only be a line
per DataAvailable event triggered?
>
>Set :
>WSocket1.LineMode := TRUE;
>WSocket1.LineEnd := #13#10; // whatever you need
>
>Note that calling the message pump from an event handler will mess all
>things.
>
>--
>Contribute to the SSL Effort. Visit
>
>--
>francois.piette (AT) overbyte (DOT) be
>Author of ICS (Internet Component Suite, freeware)
>Author of MidWare (Multi-tier framework, freeware)
>http://www.overbyte.be
>
>
>--
>To unsubscribe or change your settings for TWSocket mailing list
>please goto
>Visit our website at http://www.overbyte.be