Rebol and UDP
[1/11] from: mat:eurogamer at: 24-Nov-2000 22:27
Hello,
Just wondering if anyone had done any work with UDP ports in Rebol?
I've done what I needed to do (sending RCON commands to game servers)
but since UDP isn't a guaranteed protocol I'm sort of wondering how
one handles transport control to do it properly.
Or does Rebol do it automatically when opening a UDP:// URL?
--
Mat Bettinson - EuroGamer's Gaming Evangelist with a Goatee
http://www.eurogamer.net | http://www.eurogamer-network.com
[2/11] from: mat:eurogamer at: 25-Nov-2000 15:32
Heya Mat,
MB> Or does Rebol do it automatically when opening a UDP:// URL?
Really not having much luck with this ML am I? :(
--
Mat Bettinson - EuroGamer's Gaming Evangelist with a Goatee
http://www.eurogamer.net | http://www.eurogamer-network.com
[3/11] from: russ::portone::com at: 25-Nov-2000 12:17
Mat, there is nothing guaranteed about UDP (as you said) since it's
essentially a "one-way" transmission. It just sends blindly and hopes the
packet gets through to someone who wants it. If you want guaranteed
connectivity, use TCP or build your own two-way acknowledgement/retry
scheme on top of UDP. I cannot say what scheme your game site uses. And
I'm not sure you can really do it easily in Rebol since I dunno if you can
access the packet identifier word. Someone more knowledgable of the
innards of Rebol would have to answer that. If not, you'd need to build
some kind of packet ID into the data format of each packet sent... create a
timeout on the sending end... resend if you didn't receive an
acknowledgement from the receiver in time, etc. Basically, build TCP!
:) Hope this helps. Russ
At 03:32 PM 11/25/00 +0000, you wrote:
[4/11] from: mat:eurogamer at: 25-Nov-2000 18:16
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.
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!
Quite. The game uses UDP so TCP isn't an option. It's fairly academic
since my use now is to a server on the same box so it's more or less
guaranteed to work.
--
Mat Bettinson - EuroGamer's Gaming Evangelist with a Goatee
http://www.eurogamer.net | http://www.eurogamer-network.com
[5/11] from: petr:krenzelok:trz:cz at: 26-Nov-2000 2:31
----- Original Message -----
From: Russ <[Russ--PortONE--com]>
To: <[rebol-list--rebol--com]>
Sent: Saturday, November 25, 2000 6:17 PM
Subject: [REBOL] Re: Rebol and UDP
> Mat, there is nothing guaranteed about UDP (as you said) since it's
> essentially a "one-way" transmission. It just sends blindly and hopes the
<<quoted lines omitted: 3>>
> I'm not sure you can really do it easily in Rebol since I dunno if you can
> access the packet identifier word.
I think not. But is it needed? I am not sure how it is done in rebol, but I
think REBOL will accept only those packets itself, which contain IP of
appropriate computer in IP or TCP header, and what's more - there is a
number of local port OS assigns to rebol port. So you will surely receive
just packets which are targeted to your computer.
And if you mean obtaining packet number identifier to find out which packets
you miss from the sequence of packets you receive, it's not imho possible
with REBOL. Think in terms of buffered REBOL ports. You have buffer for 10k
bytes set, and it means you will gather more than one packet in there. REBOL
would have to store packet identifiers in a block somewhere in port object
structure, till you read out related data out of the buffer. Hmm, now as I
think about it - without such functionality, UDP implementation in REBOL is
pretty useless then, no? Holger?
Also - port/state/flags doesn't seem to be "real" IP datagram flag
representation (SYN,ACK,URG,FIN,RST)
Well, but take me easy, I am just learnig a little bit from friends
struggling with Scenix TCP/IP stack implementation :-)
> Someone more knowledgable of the
> innards of Rebol would have to answer that. If not, you'd need to build
> some kind of packet ID into the data format of each packet sent... create
a
> timeout on the sending end... resend if you didn't receive an
> acknowledgement from the receiver in time, etc. Basically, build TCP!
Very true I think ...
> :) Hope this helps. Russ
Or it doesn't :-)
Cheers,
-pekr-
[6/11] from: holger:rebol at: 25-Nov-2000 17:58
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
<<quoted lines omitted: 3>>
> 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
[holger--rebol--com]
[7/11] from: mat:eurogamer at: 26-Nov-2000 2:22
Heya Holger,
HK> It is extremely unlikely that any game makes use of this.
Quite, and it's not like I'd use Rebol for anything hard core with
game traffic. I've got my game server RCON script working nicely with
these existing UDP support so I'm happy!
--
Mat Bettinson - EuroGamer's Gaming Evangelist with a Goatee
http://www.eurogamer.net | http://www.eurogamer-network.com
[8/11] from: holger:rebol at: 25-Nov-2000 18:07
On Sun, Nov 26, 2000 at 02:31:13AM +0100, Petr Krenzelok wrote:
> REBOL
> would have to store packet identifiers in a block somewhere in port object
> structure, till you read out related data out of the buffer. Hmm, now as I
> think about it - without such functionality, UDP implementation in REBOL is
> pretty useless then, no? Holger?
No, see my other mail. The UDP protocol carries identifiers in the payload,
not in the header. The UDP header only contains port numbers, length and
checksum, no ID.
> Also - port/state/flags doesn't seem to be "real" IP datagram flag
> representation (SYN,ACK,URG,FIN,RST)
Confusion, confusion... :-)
SYN,ACK,URG,FIN,RST are TCP flags, not IP (or UDP) flags. They are used
internally within the TCP/IP stack, never exported via APIs.
UDP does not have any flags in its header at all.
IP does have flags in its header, but they are used to reassemble IP
fragments (within the TCP/IP stack) only, and are not useful at the
application level. The stack processes them by itself anyway.
port/state/flags is an internal field that indicates the mode of operation
at the REBOL port level. It is used to indicate things like "direct",
binary
, "lines" mode etc., and is also used to store some temporary
state. Those parts of port/state/flags which are useful for applications
are exported via the soon-to-be-documented get/set-modes API.
--
Holger Kruse
[holger--rebol--com]
[9/11] from: petr:krenzelok:trz:cz at: 26-Nov-2000 12:44
----- Original Message -----
From: Holger Kruse <[holger--rebol--com]>
To: <[rebol-list--rebol--com]>
Sent: Sunday, November 26, 2000 3:07 AM
Subject: [REBOL] Re: Rebol and UDP
> On Sun, Nov 26, 2000 at 02:31:13AM +0100, Petr Krenzelok wrote:
> > REBOL
> > would have to store packet identifiers in a block somewhere in port
object
> > structure, till you read out related data out of the buffer. Hmm, now as
I
> > think about it - without such functionality, UDP implementation in REBOL
is
> > pretty useless then, no? Holger?
>
> No, see my other mail. The UDP protocol carries identifiers in the
payload,
> not in the header. The UDP header only contains port numbers, length and
> checksum, no ID.
I read it already, thanks for the explanation ...
> > Also - port/state/flags doesn't seem to be "real" IP datagram flag
> > representation (SYN,ACK,URG,FIN,RST)
>
> Confusion, confusion... :-)
>
> SYN,ACK,URG,FIN,RST are TCP flags, not IP (or UDP) flags. They are used
> internally within the TCP/IP stack, never exported via APIs.
>
Ah, we just downloaded some net-monitor from ethereal.com and are wondering
at all the info OS throws at us :-) You are, of course, right - above
functionality is part of TCP layer. I learned one more thing about
connections - although our Scenix stack inexpectably FINed connection, we
were able to throw data at the chip and it WAS received. Then I read
something about so called "half closed" connections. It's interesting -
although server closed connection, we were able to throw more data to it -
it was just ignored at the data processing level, or so it seems to me ...
confusion, confusion :-)
> UDP does not have any flags in its header at all.
Hmm, well, I never looked so deep inside, - although our Scenix chip TCP
stack claims it supports UDP, it just receives data and UDPProcPktIn has
just one line - return :-) ... kind of great support = do it yourself :-)
What's more - I was confused as my friend told me, we could use UDP for
image transfer, store all packetIDs, then process all the number and get
back to our device asking for certain missing fragments (packets) of image
data received ....
> IP does have flags in its header, but they are used to reassemble IP
> fragments (within the TCP/IP stack) only, and are not useful at the
<<quoted lines omitted: 4>>
> state. Those parts of port/state/flags which are useful for applications
> are exported via the soon-to-be-documented get/set-modes API.
great. Is there anything more left to be advanced at the REBOL protocol
level after we will get async root-protocol? :-) Or are we just near
protocol nirvana? :-)
Thanks,
-pekr-
[10/11] from: chris:starforge at: 26-Nov-2000 12:30
#26-Nov-00# Message from *Petr Krenzelok*:
Hi Petr,
> something about so called "half closed" connections. It's interesting -
> although server closed connection, we were able to throw more data to it -
> it was just ignored at the data processing level, or so it seems to me ...
> confusion, confusion :-)
I'd recommend you get a copy of W. Richard Stevens' "Unix Network
Programming, Networking APIs: Sockets and XTI" 2nd ed, published
by Prentice Hall (ISBN 0-13-490012-X), before doing *any* network
programming - low level or otherwise. The tome covers the guts of TCP,
UDP and raw sockets in gory detail.
Chris
--
New sig in the works
Explorer 2260, Designer and Coder
http://www.starforge.co.uk
--
One seldom sees a monument to a committee.
[11/11] from: petr:krenzelok:trz:cz at: 26-Nov-2000 17:00
----- Original Message -----
From: Chris <[chris--starforge--co--uk]>
To: <[rebol-list--rebol--com]>
Sent: Sunday, November 26, 2000 1:30 PM
Subject: [REBOL] Re: Rebol and UDP
> #26-Nov-00# Message from *Petr Krenzelok*:
> Hi Petr,
>
> > something about so called "half closed" connections. It's interesting -
> > although server closed connection, we were able to throw more data to
it -
> > it was just ignored at the data processing level, or so it seems to me
...
> > confusion, confusion :-)
>
> I'd recommend you get a copy of W. Richard Stevens' "Unix Network
> Programming, Networking APIs: Sockets and XTI" 2nd ed, published
> by Prentice Hall (ISBN 0-13-490012-X), before doing *any* network
> programming - low level or otherwise. The tome covers the guts of TCP,
> UDP and raw sockets in gory detail.
Thanks for the tip, will take it into consideration. I have already one
really good book, with enoufh pictures and diagrams, I just lended it to my
friend, and read only the bits of the book. I feel very comfort with info I
got of it. My knlowledge of networking stuff (which I always hated and
sweard I will never learn about :-) is getting better and better. It's fun
to observe communication of REBOL with ethernet + TCP based device
microcontroller :-)
Thanks, anywa,
-pekr-
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted