> I've done a lot of work before with serial communications, but it seems
> that things don't work as simply as RS232/485 in the IP world.

Actually a lot simpler with TCP/IP :-)

> I'm setting up a client/server situation using ICS's WSocket &
> WSocketServer. These modules need to be able to transfer lots of data
> blocks between each other with little (or no) time gaps between them.

That's not quite correct. At most you could say the TCP/IP stack is not able
to do that, but that is also probably no correct.


> Now, in the old serial world, I could use fixed length packets, CRC's,
> inter character/message timeouts etc to validate & separate each block,
> but I can't do this with TCP/IP it seems.

Fixed packet length if UDP in TCP/IP world.
UDP is a datagram oriented protocol (that is fixed length packet). You don't
have to worry about the lower level details, it is handle by the UDP
protocol which will deliver your packets using "best effort" (It means there
is no retry for you).

> I read somewhere about IP not being guaranteed, but that TCP compensates
> for that, but needs to be done client side.
> Is this inside the network protocol or the components, or should I be
> doing something for this?

TCP is a stream oriented protocol which guaranties delivery of packet, do
error detection and correction for you. You can be sure the destination
receive your packet or to get notified by an error condition if your packet
can't be delivered (network failure, timeout, and the likes).
But TCP being a stream oriented protocol, the receiver doesn't know how data
was sent. Packet boundaries are not preserved.

See "TCP/UDP primer" document available from support page at my website for
more details.

> If a packet is sent by the client, can I 'guarantee' that I will receive
> every byte at the server? (& vice versa)

Using TCP: yes.
Using UDP: no.

>  From what I can see, there is nothing in the components that can tell
> me when the packet has started/completed, so how would I know what
> position of the packet any received byte is? Is there any way to
> identify a start byte/packet? If not, how can I break down the TCP/IP
> data into the individual packets being sent?


See "TCP/UDP primer" document available from support page at my website for
more details.

> I guess one way would be to introduce start/end characters to look for,
> but in this situation, all I have is a 4-byte length header. But I see
> no way to detect these four bytes.

See "TCP/UDP primer" document available from support page at my website for
more details.


--
Contribute to the SSL Effort.
Visit http://www.overbyte.be/eng/ssl.html
--
[EMAIL PROTECTED]
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 http://www.elists.org/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be

Reply via email to