Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

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