Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Server non-graphical mode?
11-01-2006, 09:26 AM,
#1
Server non-graphical mode?
Is there a way to run vdrift on Linux in a "server mode" that just acts as a server process with no GUI? Maybe I missed something obvious?

I have a Linux server in my house that does email, nfs ~/Desktop, etc., etc. for the Macs that I use as front ends for the family. The Linux box is character mode console only, don't need/want X Window on it.

If we could setup the server to be the "vdrift server" as a console app that would be pretty cool. Could even setup an rc script...

TIA
Reply
11-01-2006, 03:09 PM,
#2
 
I have thought of making a server-only mode for VDrift but since the network mode doesn't work that well it hasn't been done yet. It would be handy for testing, and probably not hard to set up.
Reply
11-01-2006, 05:34 PM,
#3
 
thelusiv Wrote:I have thought of making a server-only mode for VDrift but since the network mode doesn't work that well it hasn't been done yet. It would be handy for testing, and probably not hard to set up.

I'd like to plant a seed if I may. Smile

Add a non-graphics server mode to the software.

Also add a way to create a "mesh" or "hierarchy" of vdrift server peers.

Internet connected peers can host unique tracks and/or road sections.

The admin of each peer can regulate which series of tracks on one peeer are connected to another.

For the non-design type admins this could be as simple as interconnecting paddocks of connected tracks via a "straight section" of road. So, peer 1's 'Ring is connected to peer 2's LeMans which is connected to peer 3's custom stretch of custom track is connected to peer 4's stretch of custom track is connected to peer 1's 'Ring again. Makes a distributed huge track.

For extra fun, make it easy to import TIGER data (openstreetmaps.org) into vdrift and distribute it.

I know, kinda crazy getting carried away. Hey, it's a long commute home in the evenings. Lots of time for crazy ideas to get carried away.

I'm going to look into designing tracks soon. Blender is going to take a few dedicated evenings to get into.
Reply
11-01-2006, 07:24 PM,
#4
 
I was thinking we could skip the non-gui server part for now, and concentrate on opening up the option of more than one client computer connecting for a race. From there it's a much smaller step to an actual server.

Can anyone provide some insight into how much additional load it places on the server system to have a client logged in? Might be important information to have before going and coding a network socket that will allow 1000+ connections Smile
_____
Cotharyus
Remember: Horsepower is how hard you hit the wall. Torque is how far you take it with you.
http://cotharyus.net
Reply
11-02-2006, 01:58 AM,
#5
 
Keep in mind that the lower-level network code (the stuff in net.cpp and net.h) works fine (although it could be cleaned up a bit and then easily extended for multiple connections) -- the part that really needs to be rewritten is the multiplayer code.

But to answer your question, I don't think anyone needs to worry about more than 8 or so cars for now -- especially considering the sound engine will likely run out of sources well before then....
Reply
11-02-2006, 01:56 PM,
#6
 
Yes, I was sort of looking at all of this. It seems like to me we need to do something in terms of communicating the center point of the car, the type of the car, the state of the car, etc. to the machines connected, and let them render the car appropriately from there. Any thoughts or pointers on this? Also, how much bandwidth do we use with the current network setup?
_____
Cotharyus
Remember: Horsepower is how hard you hit the wall. Torque is how far you take it with you.
http://cotharyus.net
Reply
11-02-2006, 10:54 PM,
#7
 
Currently we're just basically streaming a replay over the network, which consists of control inputs and, in case things get out of sync, the car's state (sent every second). The controls are then input into the second car and all of the normal physics are applied. This has some advantages in that 1) it's pretty low-bandwidth, 2) the car behavior should be generated perfectly, 3) cheating is virtually impossible, 4) there's no control or response lag. This has some disadvantages as well: 1) no collisions, 2) no prediction so you don't really know where the other player thinks you are (that is, the two versions of what's going on aren't synced up, although this could conceivably be hacked in).

Right now the bandwidth usage is pretty low, maybe 2.5k/s up 2.5k/s down. I'm not sure what we should expect....

As for how to improve all of this, I have a few ideas, but it seems like a fairly difficult problem. Catch me on IRC sometime and we can chat about it.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)