Re: vaporware LOS question

On 2007-03-09 23:39:16, John Doe <NOTOSPAMjohndoe64738@xxxxxxxxx> wrote:

If you are inclined to create a proof-of-concept client/server application,
perhaps a simple one that simply pings back and forth a few hundred times per
second with variable-length packets (and provides metrics on its performance
afterwards) would be sufficient, rather than a full-blown RL. Or, if you haven't
got the time for that, write up a document on how it would be implemented, and
calculate the bandwidth savings. Nobody's saying it has to be done today, so
take your time and do a good job if you do start something like that.

I'm fairly skeptical about the benefits of inventing a leaner protocol versus
the time required to do it, but if you can do it, go ahead. Your efforts would
only serve to better the roguelike genre, right?

I can only offer a philosophical discourse :)

I find a good philosophical discourse most enjoyable! There are a few
assumptions you make that I need to address.

I think the basic problem with TCP used in a multiplayer game
of any kind is concurrency.

Concurrency is a non-issue with Angband. Angband does not process anything
concurrently. (In fact, it is single threaded and very linear in its
processing.) Everything happens in a set order, and that order must be preserved
for presentation to the player. Even the things that happen within a sub-turn
energy unit - those little things are processed in a specific order. More on
this after the next block!

In any multiplayer game many events happen in parallel, while TCP is an
ordered stream-oriented protocol. This means events need to be given
order, some kind of precendence to be packaged into the stream, while
they are in principle equivalent, having happened in parallel.

Remember, we're talking about Angband here. All of those fine details are
processed in order, and that takes nanoseconds. The only possible concurrency
scenarios are (a) timed events happening (which should set a flag for game
processing to use later, which nullifies this scenario) and (b) two players
doing things that conflict at the same time. If two players hit movement keys to
enter a store at the exact same time and the packets arrive at the server at the
exact same time... well, since all networking devices are FIFOs, one of them
will go first, and there's nothing that can be done about it save for buffering
and flushing and writing some ridiculously complex algorithm that ultimately
picks one to go first anyways.

Also, TCP is connection oriented, not necessarily stream oriented. Some
networking libraries provide a stream interface to TCP connections, though.
Using TCP as a stream is not necessarily appropriate - using it as an
established route to send and receive occasional frames of data is more
appropriate.

An additional problem is with a chuck of the TCP stream being
delayed - then TCP will not provide the data it received after the
delay to the application, as it would be out-of-order, further
increasing the delay already incurred by assigning order to
concurrent events.

The delay incurred by assigning order to non-existant "concurrent events", if
they were to magically come into existence, would be on the order of
single-digits of CPU cycles. That is, if your network hardware doesn't take care
of most of them in its own processing unit anyways. You will have to deal with
all of this and more if you decide to write a reliable UDP-based protocol... the
underlying Ethernet frames travel through the wild, and occasionally they do
disappear or get corrupted. It's part of the risk of playing an online game.
Just ask anyone who plays Counterstrike, Starcraft, World of Warcraft, etc if
lag kills them sometimes, and the answer will be yes.

TCP is a "reliable transport protocol" as per its spec, and the host OS's TCP
stack takes care of retransmission requests. Your code doesn't need to
implement its own stack and have a larger memory footprint, and the OS coders
are typically more experienced than we game developers when it comes to these
things. Don't let that stop you from earning fame and fortune by making things
better, though. In fact, if you can make new, more efficient code, you could
wind up inventing the next Internet Protocol. But if you don't have time to make
a roguelike, that ain't gonna happen. Just sayin'. :)

In order to create the best connection quality, you have to plan ahead for
Ethernet frame sizes. Fragmented packets often are the largest cause for
retransmission. Large numbers of packets are a good way to DOS a server or
client, causing lag-outs. So there has to be a median somewhere.. don't send
everything, and don't send one little piece at a time.

Something else I failed to mention earlier: TCP Out-of-Band data functions much
like a UDP packet, and can interrupt a stream with megabytes of queued packets.
The issue of "oops, my stream has backed up packets, and the player wants to
abort their processing" goes away real quick when you use that! It could also be
used to tell a client to stop processing any queued macros, since the player has
just died. :)

Now, don't get me wrong. I'm not advocating laziness here. Airtight, bulletproof
network code is absolutely necessary to avoid a bad player experience. But it's
not necessary to reinvent the wheel when your idea has already been implemented
and the code has matured for decades!

If you really want to make your own protocol after reading all that, here's a
starting point. Take an existing open-source TCP implementation, change the
magic numbers to avoid confusing things around the 'net, and remove all the
stuff you don't need. That should be a lot less problematic than rolling your
own!

Good debate. I'm interested to hear your replies, and I'm very interested to
know if you have in fact written any networking code.

- Berendol
.

Relevant Pages

  • Re: TCP question
    ... It's a stream. ... by its nature it behaves more like a stream at the TCP level. ... the code you have for receiving the packets ... Consecutive packets can even take different routes from sender ...
    (microsoft.public.vb.general.discussion)
  • Re: OS X packet sniffing tools
    ... which has the nice feature of being able to show the TCP ... ability to display the TCP stream. ... X11 though. ... Seems a bit heavy just to get some packets. ...
    (uk.comp.sys.mac)
  • Re: Winsock - how to insure packets are received?
    ... There are no packets, only a bidirectional stream. ... TCP works hard to abstract away the actual packets involved, and couldn't possibly care less about how often you call SendData or the size of what was "sent." ... If you want framing you have to add framing. ... And before "deblocking" your message frames from the stream you have to reassemble the received stream fragments. ...
    (microsoft.public.vb.general.discussion)
  • Re: NTP and Firewall help needed.
    ... >port 123 for udp and tcp. ... Also the idea of combining rules for packets arriving at the local machine ... ACCEPT any and all traffic coming from the localhost interface ...
    (comp.os.linux.setup)
  • Re: UPD better than TCP in streaming video/audio ?
    ... > UDP gains speed over TCP because it carries no information that would ... it doesn't even know that packets were lost. ... which is perfect for UDP. ... > Finally, there's the possibility of multicast data - for instance, a live ...
    (microsoft.public.win32.programmer.networks)
Loading