You need to decide a few things first.
Do you want really want defined packets, or will a stream work?
If you are going to be transmitting packets, then you should size the
packets according to your average document size. For example, if your
document is normally 1K (1024 bytes) then it makes sense to send the
document in a single packet sized to 1024 data bits. If your document is
100K, then you will want to break the document into packets sized at a
maximum of say 4K. The larger the packet size, the fewer packets will need
to be handled. On the other hand, the larger the packet the larger your
retransmit time will be if such packets get corrupted or are received
incompletely. Smaller packets mean more transmissions, but your retry rate
is much lower. You should write your packet handlers to be data size
configurable, so that you can tweak the connection for best performance.
Simple packet:
<start identifier><data length>[data segment]<end identifier>
Anything in "<>" is considered statically sized. Anything in "[]" is
considered dynamically sized.
STRING = "TESTING"
PACKET = CHAR(27):"A"
PACKET := LEN(STRING)"R%6"
PACKET := STRING
PACKET := CHAR(27):"E"
<esc>A000007TESTING<esc>E
"R%6" will give you 99,999 byte maximum data size in the packet. Keep in
mind that when you design a packet structure, the length of the start block,
length block, and end block are all static byte lengths. If you make a
change and expand say <data length>, then you will need to update every
piece of code that uses the packet design. Otherwise everyone will get very
confused!
Incoming packet-> MYPACKET
IF MYPACKET[1,2] = CHAR(27):"A" THEN
IF MYPACKET[LEN(MYPACKET),2] = CHAR(27):"E" THEN
DATASIZE = MYPACKET[3,6]
DATABLOCK = MYPACKET[9,DATASIZE]
END ELSE
GOSUB WAIT.FOR.DATA
END ELSE
GOSUB WAIT.FOR.DATA
END
END
This is definitely pseudo code that has 99% of the logic missing. Even if
you are streaming data, both sides need to understand at least two static
packets defined for error conditions.
Retry
Received OK
These short packets should be communicated uni-directionally and in
sequence to the data packets. When sending a packet, the process should
withhold continuing until a "Recevied OK" or "Retry" acknowledgment is
received. A receiving packet should be verified immediately and the other
side should be notified of either a "Retry" or "Received OK" scenario. For
all of the communication steps, timeouts should be an integral part and
initiate a Retry or quit with a fatal error upon serious or repeat problems.
For more info on packet designs and possible pitfalls with various socket
types and layers, Google for "socket packet design".
-------------------------------------------
Glen Batchelor
IT Director
All-Spec Industries
phone: (910) 332-0424
fax: (910) 763-5664
e-mail: [EMAIL PROTECTED]
-------------------------------------------
www.allspec.com
-------------------------------------------
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:owner-u2-
> [EMAIL PROTECTED] On Behalf Of Sunny Matharoo
> Sent: Wednesday, August 23, 2006 10:22 AM
> To: [email protected]
> Subject: [U2] TCP/IP Standard Packet design
>
> Hi
>
> Being new to this type development, does anyone have advice on how to
> build a standard packet.
>
> What we will be doing is to prebuild an XML file and to it this we will
> be sending over TCP to the server.
>
> Any suggestions would be great
>
> R,
>
> Sunny
>
> Sunny Matharoo
> Development Team Leader
>
> Tristar Worldwide Chauffeur Services
>
> Tel: +44 (0) 1895 432074
> Fax: +44 (0) 1895 432098
> E-mail: [EMAIL PROTECTED]
>
> www.tristarworldwide.com
> -------
> u2-users mailing list
> [email protected]
> To unsubscribe please visit http://listserver.u2ug.org/
-------
u2-users mailing list
[email protected]
To unsubscribe please visit http://listserver.u2ug.org/
