Oops, I meant to reply to the list but instead I only sent the links to Drew. Here they are:
http://www.gamedev.net/community/forums/showfaq.asp?forum_id=15
http://www.gamedev.net/reference/articles/article1138.asp

On 11/2/06, Nicolas Chaufette <nico1965_nico@yahoo.fr> wrote:
I'm sorry to "interfer" but I'd like to know how many of you are actually working on the network engine, or only thinking how it could be improved, because I'm also in that process and I think, well, we could work together, otherwise some of us are just loosing their time

I think working together is a great idea...so let's continue this discussion until we agree on how things should work, and then begin actually reworking VDrift's network code. Then we can decide how we'll divide up the coding task, if there are more than one interested and capable coder, and go from there. This may even warrant setting up a new branch of VDrift in SVN, as it may take a while to get all the changes done and working right.

about you remark on UDP :
actually I did a (messy) network engine for another game, on top of these "low levels" protocols UDP and TCP, and now I'm looking at RakNet API ( http://www.rakkarsoft.com), I'm realizing I lost my time writing what had already been written, because 90% of games protocols always work more or less the same way, and the 10% remaining can very easily be implemented on top of existing APIs. Just take a look at RakNet or OpenTNL ( http://www.opentnl.org)

If I remember right, when Joe first started writing the net code for VDrift, he looked at OpenTNL and decided it did way more than we needed it to. This is why we ended up using SDL_net, it is simpler and does pretty much everything we need - as far as I know...

On 11/2/06, Matthias Heinz <mh@familie-heinz.name> wrote:
The 1:1 code seems to base on the replay code and yes there's no collision
right now.

Yep, that's right. So for a client A and server B, all that happens during a network game (as I understand it) is A sends B replay frames of itself, and B sends A replay frames of itself, so each one can draw the other. What *should* happen is the client should send this data to the server, then the server should process it as part of a pool of cilents (of whatever size), look for collisions and other stuff, and then send feedback data to the client. This feedback data would include position of other cars, how the client should react if there are any collisions, etc.

I think i might get a some server ressources on a german server of a gaming
under linux website (who knows holarse.net?). I haven't talked to the owner
yet, but they're running some other dedicated servers there, so i think
they'll say yes.

This sounds like a great idea, but of course we need to get network play working much better and set up a dedicated server first. But this is a good goal to work towards. 

Well, there're some problems for the net thingy to solve first. If you want to
have collision in network gaming there has to be a rework of the code that
places the player at the start. Currently there's a position where the player
car gets dropped (yeah, really dropped).

Yep, we need to be able to set up a list of start positions, so that if multiple players are in a game, they can all have a different starting place (right now they all start at the same place...on top of each other). 

My idea for the trackeditor would be a square or something else that can be
moved just on the road and there the car will appear. And the add other
squares for the next starting places. (or a square and behind it a bezier
curve with which you can set the track arrangement or else, just my ideas).

The reason the car is dropped when the game starts is that if we don't place it somewhere above the ground, a tall car runs the risk of starting with wheels embedded in the ground. The cars all begin with their suspension fully distended, that is, the wheels hanging all the way down as far as they go. The car then settles down on its suspension when it lands. The user doesn't see this drop take place, instead this happens before the game begins drawing, we use something called "trimming" to make sure the car has stopped before we begin the simulation.

So, while perhaps there's a better way to do the car placement in the track editor, there's nothing wrong really with dropping the car there. As far as I understand we're not the only car game that does placement this way. If you know of a better way please share it...but I don't see any terribly compelling reason to change this.