--- Erik Hofman <[EMAIL PROTECTED]> wrote: > I must say I don't have experience in this part of > the code, but to my > knowledge the OLK code was able to do it, so there > must be some code to > do it (I guess the OLK code could give you some > clues). > > One thing to think about also is the way you want to > implement this. > There are several ways (FlightGear connecting to all > other players, or > connecting FlightGear to a daemon (which could run > on another computer). > > The basic idea I like best is to have a 'network' > server which serves > all clients of a local network (LAN). This server > the could handle > connections to other LAN servers then. > > If I'm not mistaken PLIB already supports some kind > of a LAN host. > That's another part of the discision, will you be > using a guaranreed > protocol (TCP) or is a fire-and-forget protocol > (like UDP) good enough. > You should take into account that the latter > requires less from the > client, but it _is* possible you would lose data > once in a while. > > So it takes some care to decide the right type of > connection (for > whatever data you want to sent). > > Erik
Some decisions were already made. UDP is the way to go. Just look at all other multiplayer games out there and say that they use TCP. (NOPE) They use UDP or IPX (where IPX is the non-stream version of a Novell network protocol called SPX (well not exactly... but you might get the idea)) With TCP, if a packet gets lost, then it will retransmit after a given timeout, for example 3 secs. The data would be obsolete by then. With UDP, if it was a important message, we would confirm it. When it was position data, we would just wait for the next one (which would arive within 0.5 secs) Because we have to(?) support 56k modem users I think of using 512byte UDP-packets, that way modem users can sent about 5 updates p/sec and receive 7 p/sec. With a flight sim packets per second doesn't really matter, we are well capable of predicting where a plane is for about 3 seconds. I never seen a plane strafing or flying backwards all of a sudden :) Client-server model is chosen. Simply because you can run the server deamon at the same machine as the client and we don't have to recompile the entire game too much. Another advantage is the fact that we can introduce new IA-players by creating a 'fake' client. Also we don't know the connection speed of every PC and 56k users should be forced to runn a server. The first important decision now is, do we multi-threading or multiplexing-IO ? For multiplexing, PLIB can be used. For multi-threading, we got a problem. Another issue is how to get the code to compile on other platforms, because threading and sockets aren't 100% portable, to say the least. Far Future: The most interesting feature would be a distributed server architecture (world wide coverage with multiple servers), but we won't start on that until the simple server is 110% stable and all interface are completed. So this will not be implemented in this round. Leon __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
