of course you can help! I think we must make some decisions first. Should
we put the discussion and the decisions into a Doxygen-file in the CVS?
Here is what I can come up with:
- How to use threads?
- The code must be portable.
- It must communicate through firewalls.
- We need some kind of clock synchronization.
- We need object naming and addressing.
- Bandwidth requirements must be low because of modem users.
- Number of ports use must be low to scale with number of users.
- UDP should be supported to scale with distance.
- Must all events be ordered and synchronized? How to order and
synchronize events where necessary?
- How do we create protocol payload? Hand-made? XDR? Something else?
The code I uploaded is only the very lowest-level messaging stuff. I'm not
sure how much of it we can keep but since I have my priorities on komssys,
I could do more if we use a lot of this. It runs on several Unix' but not
on Windows, Cygwin failed because we use recvmsg().
On object naming and addressing. Clients and server can create objects
with unique "names" but only the server can assign unique addresses.
Rockets, torpedos, bombs, cargo cans, even ship wreckage can have
pre-assigned addresses, but is that efficient?
So what do you think about all of the following?
My idea is that we should have the game thread and an additional network
thread (both client and server). I know about the problems of
multithreading. But we could loose packets in the kernel receive buffer if
we have only the rendering thread that polls the socket. Unless we use IO
interrupts which is even worse than threads.
Arriving: The network thread waits for packet arrival and dispatches them
to objects in the game. Ordering, delaying, synchronization and so on are
handled by the objects.
Sending non-action data: The network thread sends non-action data. TCP,
RTCP and "TCP-friendly rate control" can be used to compute the available
one-way bandwidth. The thread could 'poll for dirty objects': if the state
of an object has changed twice before the next packet is sent, only one
update is sent. Better/partial retransmission is on top of my TODO-list.
Examples: all trade-related data, results of ship scans, ship damage
reports, downloads of all kind, messages between players.
Sending action data: Action data is sent by the game thread as quickly as
necessary and possible. The ports are the same as before. Examples:
units created, shots fired, joystick movement.
You're of course right about the firewall problem. As said, the
connections setup is negotiated over TCP, so that at least should work.
We could probably probe whether UDP communication is possible, or whether
we have to use TCP. Someone is currently putting TCP into komssys as an
alternative, so this code should exist shortly. The SHs in komssys/rtp/sh
can also be used to plug a proxy together, so we could make a translation
from TCP to UDP somewhere in the net.
I know that there are a few firewall proxies that can negotiate
temporarily open UDP ports via H.323. Does anyone know about something
similar for RTSP? RealPlayer allows clients to set permissible port
ranges, or fixed UDP ports in the worst case. We could do the same:
rtp/rtp/MNRTPSockets.* is used to choose UDP ports.
On Thu, 11 Jul 2002, Dave Jeffery wrote:
> On Saturday 06 July 2002 20:27, Daniel Horn wrote:
> > On Saturday 06 July 2002 06:04 am, Carsten Griwodz wrote:
> > > Hi Daniel,
> > hello! Carsten is around!! :-) yahhooo
> > > my answer to your question about the networking status was
> > > loudmouthed and optimistic. Instead of fighting against SCTP any
> > > longer, I have turned to my komssys code. I have uploaded a file to
> > >
> > > vegastrike.sourceforge.net:/home/groups/v/ve/vegastrike/net/komssys
> > >.tgz
> > I'll download an run :-) sounds like a solid start
> > > There are many files that are not needed for Vegastrike but the
> > > vsclient and vsserver example in komssys/vs use a TCP connection to
> > > set up a UDP "connection", and send packets back and forth until
> > > you CTRL-C.
> > excellent :-)
> > > Pretty useless right now. Just so you know that there is code and
> > > that I'm not dead. More to come.
> > cool glad to hear from you again...hope that there will be some more
> > interesting code for VS :-)
> > I have made some excellent progress on mission scripting...now
> > missions have a way to serialize themselves... for saving
> > currently---but in the future so they'll be usable over a network...
> > :-) this is called pickling in python which is what I'm transforming
> > the scripting to use...
> > I'm sure we'll get this multiplayer thing together...but it's a tough
> > shell to crack--once we get a nice foothold there willb e a lot for
> > everyone to contribute on
> > > - Carsten
> Well if Carsten can make a return so can I now that life has returned
> to some sanity.
> Carsten, anything I can do to help? If so, just let me know. Also,
> have you thought about the fact that your current UDP setup code won't
> work reliably with a client behind a NAT connection? If someone
> doesn't see why, ask and I'll explain. Of course, if someone thinks
> my assessment is wrong then speak up!
> David Jeffery