On Sat, Nov 25, 2000 at 06:16:52PM +0000, Mat Bettinson wrote:
> Heya Russ,
> 
> R> packet gets through to someone who wants it.  If you want guaranteed
> R> connectivity, use TCP or build your own two-way acknowledgement/retry 
> R> scheme on top of UDP.
> 
> Well that's my point, I don't know if the high level Rebol UDP support
> does this for you or not. If it doesn't, it'd be fairless useless as
> you can't get access to packet ids like you said.

REBOL provides UDP support in pretty much the same way as other languages.
UDP does not have any packet ids. With the standard socket API you only
transmit and receive the UDP payload. Real-life protocols built on top of
UDP (e.g. DNS) all provide their own IDs for sequencing, as part of the
UDP payload, i.e. you can access those IDs with REBOL in the same way
as with other languages.

There is a packet ID field at the IP layer (below UDP/TCP), but this is
typically only used for IP-internal things (such as IP fragment reassembly)
within the TCP/IP stack. That ID is shared among ALL applications and thus
wraps around too quickly to be useable at the application level (plus the way
to access it is not fully standardized across Unix versions). It is extremely
unlikely that any game makes use of this.

> R> some kind of packet ID into the data format of each packet sent... create a
> R> timeout on the sending end... resend if you didn't receive an 
> R> acknowledgement from the receiver in time, etc.  Basically, build TCP! 

Not really. If you need a reliable stream protocol use TCP, don't build it on
top of UDP. UDP has other advantages, e.g. it lets you adjust the bandwidth
you use for a transmission based on observed packet loss. TCP does not allow
that -- it would block. Yes, you need to build your own ack/retry protocol
on top of UDP to get reliability, but that is easy to do. You should look at
the higher flexibility of UDP as a feature, not a problem. If REBOL tried
to put its own ack/retry protocol on top of UDP then the result would no
longer be UDP, and it would not interoperate with existing applications.

-- 
Holger Kruse
[EMAIL PROTECTED]

-- 
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubscribe" in the 
subject, without the quotes.

Reply via email to