[bf1942] Linux server status update 2003-04-28

[ScratchMonkey]

--On Tuesday, April 29, 2003 5:06 PM +0200 Reinder Gerritsen 
<reinder at strikerz.net> wrote:

> my guess is dat a UDP parser on the recieving end, be it the same server,
> or a totally different one is the most flexible and easy-est to implement.

TCP, not UDP. We're talking about a continuous stream of data, not isolated 
time-sensitive packets, so TCP is more efficient, as it encapsulates the 
retries and acks.

Note that TCP is only expensive for games and multimedia (video/audio) 
because in those cases you're working over a potentially unreliable medium 
and you want to ignore dropped packets, not retry them. For an extended 
communication over your loopback interface or a quiet LAN, you've got a 
reliable error-free connection so there are no retries to kill your 
throughput.

But I don't think DICE should implement this. As I've said before, DICE 
should just make a simple file-writing DLL/so and let us drop in a custom 
replacement for exotic stuff like sockets to remote log processors.

(Because the stock library would be dirt-simple, DICE could provide source 
to it so it could be used as a skeleton for 3rd parties to extend from. 
There shouldn't be much more to it than fopen, fclose, and fputs.)