Messages

1

RaptorNL / Re: Defining Reliable / Unreliable and Ordered / Unordered

« on: November 22, 2006, 08:15:21 am »

My references are my experience and the linux man page socket (7), first paragraph:

       This  is  an  implementation  of  the  TCP protocol defined in RFC 793,
       RFC 1122 and RFC 2001 with the NewReno and SACK  extensions.   It  pro-
       vides  a  reliable, stream-oriented, full-duplex connection between two
       sockets on top of ip(7), for both v4 and v6 versions.   TCP  guarantees
       that the data arrives in order and retransmits lost packets.  It gener-
       ates and checks a per-packet checksum  to  catch  transmission  errors.
       TCP does not preserve record boundaries.

It explicitly states that record boundries are not respected. The RFCs (the protocol specifications) will tell you the same.

Nagle (I spelled it wrong the first time) is an algorithm that delays outgoing TCP packets in an attempt to join them into 1 larger packet. This is done to improve bandwidth efficiency for interactive traffic. It is turned on or off with the TCP_NODELAY flag. Even if you do not use Nagle, records can get joined or split by network delays, MTU limitations, retransmissions, cpu load and so on. (if you write out 2 x 1000 bytes in rapid sequence, it will most likely arrive as 1 packet with 1460 and 1 with 540 bytes. This may or may not be presented to you as 1 read of 2000 bytes or 2 seperate reads).

About the delay sensitive, I would definatly NOT send them over the reliable channel. An example of delay sensitive data could be trajectory data of objects in your world. Retransmission would only make the delay worse. For a retransmission, the game would pause, then it would jump, in the second case, there will be a jump too, but it will be smaller. The jumps can be made smaller by sending more updates, but that would increase the chance for packet loss...

PS: As a side issue, it is the kernel that does the TCP handling, it is not the socket library itself.

2

RaptorNL / Re: Some remarks about the raptornl design.

« on: November 22, 2006, 07:45:10 am »

I am sure the HawkNL works, but is it used for servers too? Most of the things I mention are only important for the server side of the connection. As a client you won't need more than a few sockets... but the server will need the same amount of sockets per client.

3

RaptorNL / Re: Questions about the RUDP headers

« on: November 22, 2006, 07:40:29 am »

I stand corrected. I assumed you were going to implement something on top of UDP. RUDP does not work that way. It is layered on top of IP and would indeed require a cehcksum. I found my information here, including RFCs.
From what I saw however, this protocol never really got off the ground. I cannot find implementation in the linux kernel and google didn't seem to return any references for windows either.

Are you really planning on implementing it on top of raw IP? You could indeed save some bandwidth by implementing those protocols in userspace, but is it worth it? Using UDP is easier and maybe even faster (since some networking cards have UDP checksum support built into the hardware). You can still add the necessary features inside the UDP pdu. You will also have a lot less trouble with things like routers who do NAT. Current, with your protocol unsupported by the router, this would mean it is incapable of distinguishing two different client PCs behind 1 single IP. To support it you would need do some kind of channel negotiation in the connection setup.

4

RaptorNL / Some remarks about the raptornl design.

« on: November 21, 2006, 12:18:43 pm »

Hi,

I took a quick look over the code in svn and have a few remarks I'd like to make.

I am not sure if you wish to use the raptornl code for both client and server, but I've seen a few things I have my doubts about regarding efficiency and scalability. First of all you use select() extensively in the code. This has a few distinct disadvantages:

• You are limited to a fixed number of file descriptors (default for linux this is 1024, on windows this is 64)
• You must manipulate fdsets even if only polling a single fd

Most of these are solved by using poll() on unix.
For windows it seems Completion Ports are the answer. I have no experience with these though.

From what I can see there is also no way to do any sort efficient input polling. The only way to know if any socket has data is to poll them all. This is only acceptable if you only have a few sockets.

5

RaptorNL / Re: Defining Reliable / Unreliable and Ordered / Unordered

« on: November 21, 2006, 11:45:19 am »

An important difference I have not seen mentioned is that UDP is packet based and TCP stream based. For the upper layers, in TCP there is no such thing as a packet. You data will arrive as one continuous stream of bytes. From the headers i've seen in your spec, you are not prepared to handle that (since there is no way to see how long the data segment of a packet is, only the header). Also, there is no guarantee that if you receive data it will be a complete packet.

Another feature I haven't seen mentioned either is the difference between delay sensitive and not-delay sensitive data. For a game, I think that might be important. Especially if you consider mixing TCP and UDP as a transport layer. TCP can introduce extra delays because it will queue sending data in an attempt to compose larger packets (Naggle).

6

RaptorNL / Re: Questions about the RUDP headers

« on: November 21, 2006, 11:29:23 am »

Why are you including a checksum in the packet?  The UDP header already contains a checksum of both header and data.

If the UDP packet arrives, it's contents are as errorfree as a checksum can make them, so adding an extra one won't do much good. If you wish extra protection, consider adding a CRC.