what would you like to see in the vegastrike multiplayer?

[chuck_starchaser]

By the way... why do you keep saying
Quote:
...you (non programmers)...
Have you been sniffing our connections?
Do you know anything about us?

OT: klauss, this guy is a renowned troll, he's been banned before at other forums, loves to get people angry. He has some weird religion-based beliefs that women are supposed to be quiet and subservient slaves to men, and that that women's rights and the women's lib movement are the cause of all our evils; --ideas that apparently his dad's been putting into his head. (I think he's very young.) So that's it: We've got a social disaster of miscomunication and resentments between men and women in our society, which is the consequence of religions having totally repressed and distorted human natural sexuality (anything BUT monogamous), and now another religious nut wants to force a "final solution" to all our problems...

He's not lying about his hacking, although I can't judge his skills since I'm no hacker myself.

Check out my thread in the off-topic forum at the bottom, for some discussions his trolling sparked.

[klauss]

I've already seen the thread.
But you know cryptography is my realm, and I can't see someone saying all the wrong things and let it go.
Besides, whatever propaganda he may have spread before, now he's been behaving, and I think we should recognize and encourage that. Don't you? (Although quite stubborn in his opinion, he's been following a pretty rational discussion)

After all, it is only an option what he asks for. We're just trying to convince him that it's not an option that will add any benefit. Its a useless option, that could be left behind should it become a nuisance in the implementation stage.

[chuck_starchaser]

You're right, I guess I have a bit of left-over anger at the way he bugged me in another thread. Not so much at his ideas; I'd love to argue with him till kingdom come or until I clarify his mind about where our men/women trouble really comes from; but at the fact that he interrupted an interesting discussion about ship design and weapons systems.

BTW, is there some secure http hack that would allow a person to run a website from home? His url starts with "https://...", but the ip belongs in the range of a cable service provider. (Don't worry, mikee, I was planning to take action against you, originally, but I changed my mind after I read some of your stuff. I would love to put your dad safely behind bars, though, --not that I think there's any chance...) Anyways, I suspect that he's found some loop-hole, something in some http implementation that didn't pay attention to secure protocols, that allows him to route a fixed ip into his home. But maybe I'm totally off.

[klauss]

At work we have that kind of connection: A dynamic IP assigned to a dynamic DNS. Will let you host from any connection, including a cable connection.

Http only needs the IP, so as long as you update the DNS every time the IP changes, you're good to go. https:// only specified that you have to connect through SSL, to the port 443 instead of 80.

As for secure, since your host is your own computer, you have as much security as your firewall provides (in our case, we have a tunnel and the two computers - the server and the internet provider) are in separate networks, so no internet packet arrives at the server, except those of incoming connections. (That assuming the router has no bugs, which you can never rule out).

As I said to mikee, SSL is pretty secure if you configure it (the server and the clients) correctly. If you want to provide a true https connection, you have to setup your own server certificate (get one from one of the CA companies out there, or get a free one from one of the free CAs also out there, or - as we do - be your own CA). Then, distribute by secure means (probably not internet) the server's root CA to the clients, and get certificates for each client. Then, configure clients and the server to only accept certificates signed by the trusted CA (in our case ourselves), and setup ciphers, and you have a secure https server. It's not simple, but it's the only way https can be truly secure.

[klauss]

Back to our theme:

Perhaps a system could be developed where a server is more of an organizer that "conducts" the universe where all of the clients each handle the processing in a distributed fashion. Systems that are currently inhabited by users would be processed by the clients of those users whereas the goings on of uninhabited systems would be processed by all of the clients. Perhaps a client validation scheme could be devised to prevent hackers/cheaters from "polluting" the game environment.

A variation of that:

Systems that are currently inhabited by users would be processed by one of the trusted servers (a.k.a. distributed serving), whereas the goings on of uninhabited systems would be processed some of the clients.

Clients, for uninhabited system simulation, would be probed for consistency by the server from time to time, by double-checking some results. Trusted servers would be special clients which, by some form of trust acquisition, acquired the trust of the VS comunity and are acceptable for serving. Those servers run like the dedicated main server, but focus on one system only, and would be able to be shut down transparently. Clients would ask the main server who's serving a particular system, and then connect to that mini-server. If the connection breaks, the client would ask again to the server, which would most probably

a) send a new server, if word got to the server that a mini-server has been shut down
b) send the same server, if the connection break was temporary
c) detect an unexpected shutdown, if many concurrent requests arrive for the same system, while the main server thinks that system is still being served by a mini-server, and assign another mini-server (which could be itself).

Provisions would have to be taken for state upload from mini-servers to servers and viceversa. Probably a steady stream of asynchronous updates, at a rate unobstrusive to the main traffice, would suffice, since the upload/download would be done for backup purposes only.

(Hey! Confed Special Ops! - only 128 more posts to ISO Party Membership)

[smbarbour]

I'm not trying to fan the flames of the TCP vs UDP argument, but it has been my understanding that UDP should be used in cases where it does not matter if the packet reaches its destination. It would seem to me that we would WANT to make sure packets are not being lost.

If I fire my gun at you and you don't receive the packets saying that I fired my gun, how would that be handled. My computer calculates that I have hit you, your computer says you are not under attack.

Am I missing something here? TCP or UDP, lost packets are bad. TCP will try again, but UDP will just ignore it.

[Guest]

I'm not trying to fan the flames of the TCP vs UDP argument, but it has been my understanding that UDP should be used in cases where it does not matter if the packet reaches its destination. It would seem to me that we would WANT to make sure packets are not being lost.

If I fire my gun at you and you don't receive the packets saying that I fired my gun, how would that be handled. My computer calculates that I have hit you, your computer says you are not under attack.

Am I missing something here? TCP or UDP, lost packets are bad. TCP will try again, but UDP will just ignore it.

We should beable to have both (since TCP is going to be used for login anyway). So a client (if the server has this set to allow it) can choose to stay in TCP or go to UDP.

[chuck_starchaser]

You make a good argument. The problem is with the way the re-sending works. The packet is re-sent between some of the new packets. But now, suppose the re-sent packet does not arrive (which happens sometimes)... There's only so much space for packets in the queues, and at some point the sending of new packets must stop to wait for the lost packet to finally arrive. That's one of the reasons you might sometimes see a download progress bar stop for a second and then continue. This would murder multiplayer synchronization.
Besides, the information in that packet must arrive within a fraction of a second, as the game engine has no provision for going back in time and saying "oh, at that point ship X got shot out of the sky, so the fact that a second later it shot ship Y out of the sky was incorrect, so I'm going to bring ship Y back into life"... You know what I mean?
The way the problem of UDP packet loss is handled is by re-sending information immediately (each packet includin a copy of the previous), and/or, to some extent, by applying data recovery (extra bits to each packet that allow, say, a single packet in a group of N packets to be recoverable from the info in the other packets). Ultimately, though, multiple packet loss would defeat data recovery and duplication, and then you have to have some exception handling policy for such an eventuality; but re-sending the packets the TCP is not an option for real-time synchronization; and instructing TCP NOT to resend packets is not an option either, so that makes TCP itself not an option, realistically.
But we can leave the option in, if that's what it will take for some people to be convinced.

[Guest]

I'm not trying to fan the flames of the TCP vs UDP argument, but it has been my understanding that UDP should be used in cases where it does not matter if the packet reaches its destination. It would seem to me that we would WANT to make sure packets are not being lost.

If I fire my gun at you and you don't receive the packets saying that I fired my gun, how would that be handled. My computer calculates that I have hit you, your computer says you are not under attack.

Am I missing something here? TCP or UDP, lost packets are bad. TCP will try again, but UDP will just ignore it.

We should beable to have both (since TCP is going to be used for login anyway). So a client (if the server has this set to allow it) can choose to stay in TCP or go to UDP.

[klauss]

Yes, you're missing that usually you don't transmit such events, but more basic events like the following, and in an absolute form that doesn't depend on previous packets:

Bolt 253 is at 0,0,3 moving towards 0,1,5 at X mps
Bolt 253 is at 0,1,5 moving towards 0,2,7 at X mps
Bolt 252 collided with Unit 23
Unit 23 shields =80%
Bolt 253 collided with Unit 23
Unit 23 shields =60%
Bolt 254 collided with Unit 23
Unit 23 shields =40%
Bolt 256 collided with Unit 23
Unit 23 shields =20%
Unit 23 hull =2100
.
.
.
Unit 23 hull =0 (destroyed)

Regard each line as a packet. So, if you miss one packet, most of the time, it does not matter. Since each client would be double-checking the simulation (for instance, bolt information would have to be inter/extrapolated), missing a "Bolt x collides with y" would not be so bad, since if the client doesn't receive the packet but in its own simulation the bolt collides, then it can put it in the delete queue. If afterwards, the client receives a bolt update saying that the bolt collided, it's a confirmation and it deletes the bolt for good. If it says it missed and is still travelling somewhere, it re-places it into the environment (creating one of the many artifacts caused by packet drops, but not an important artifact since all important things, like ship status, are alright).

If we encounter a packet that cannot be missed, we can ask for confirmation and manually implement TCP: if the confirmation does not arrive, we resend it until it does arrive. Simple.

EDIT: Sometimes, redundant updates could be sent to mitigate the artifacts. If a client misses a bolt collision update, it will most likely receive one a few seconds after. If it misses a hull/shield update, it will most likely receive one a bit later, since those updates would be continuously transmitted to mantain every client synchronized in that important aspect: hull/armor/shield status.

[chuck_starchaser]

klauss, I'm no expert in this area, but I would think each packet would probably include position and velocity vectors for all ships in the local theatre. Packets as small as you seem to propose would incurr a lot of bandwidth inefficiency from all the added headers and stuff, no?

[klauss]

You're almost right. It was just to clarify things.
Yes, each packet would convey a lot of information, but possibly not all of it (since UDP packets have a size limit and the drop ratio relates to that size too - for instance, it is more likely to loose a 1024-byte packet than a 512-byte packet).
And I'm no expert either. I just know that, but there are lots of other things I don't know and are required to create a good multiplayer engine.

[monotonehell]

When I first suggested the idea of a distributed 'server' like I said it was a half baked idea. I thought there may be some really big obvious reasons why it wouldn't work at all. But reading through what people have said it seems like the two problems I originally thought of are the only ones mentioned so far. Namely cheaters and lag.

I was thinking something along the lines of giFT. (http://gift.sourceforge.net/) Where, as clients drop in and out, the network readjusts itself. Some clients would become index-nodes coordinating others to a degree (like in giFT where some clients perform indexing), some search nodes and others simple users.

The giFT framework allows for about 500 user-nodes per search-node and it claims to be very scalable so it sounds okay in that respect. The indexing and search nodes would be very handy to localise clients within the VS Galaxy and in that way direct clients to which other clients are close by. That way a load of irrelevant telementry could be ignored.

You can check this part (http://www.cs.umu.se/~bergner/thesis/html/node66.html) in Marcus Bergner's Thesis about the state of File Sharing in 2003 for a quick run down of what each node handles and with a little creative thinking you can see how this could be adapted to share telemetery.

What people are saying about complexity of this idea and the fact that it warrants it's own project I'd agree with. It's interesting what people's opinions of this idea have been.

{ I decided to finally register a user name on here lol }

[klauss]

But reading through what people have said it seems like the two problems I originally thought of are the only ones mentioned so far. Namely cheaters and lag.

Oh... there are lots of other issues, but I'm pretty sure the reason they're not brought up is that none of us knows how to deal with them.

Namely, a few:
* Contingency handling: what to do when a server (or client serving) unexpectedly gets disconnected? What about all the info it had in it?
* What about python interaction between systems, or portions of the universe being coordinated by different servers? It is not inexistent: trading.py, for instance, accesses all systems.

They're just a glimpse at the horrid future of such project. But... if you imagine the satisfaction of seeing it work someday, many people will not mind such horrid future.

[smbarbour]

[Half-Sarcasm]
We could always design a new protocol to go over IP. TCP gets out of sync too easily and UDP has no built-in verification. We need to design VSS/IP (Vega Strike Synchronization over Internet Protocol) We'll give it all the features we want and since it is our design, it will only have the overhead we want it to have.
[/Half-Sarcasm]

This post is more of a joke than a serious consideration.... But anything is possible!

[klauss]

Well, in the end, any UDP app does that.

[monotonehell]

* Contingency handling: what to do when a server (or client serving) unexpectedly gets disconnected? What about all the info it had in it?

Doesn't matter. It's a distributed system. If one client goes offline they just disapear from the game. This is a bit annoying for someone who's about to blow them up maybe but it happens all the time in MMOGs and people deal with it. It's a distributed system - no one client holds any unique information about anyone but itself.

* What about python interaction between systems, or portions of the universe being coordinated by different servers? It is not inexistent: trading.py, for instance, accesses all systems.

Trading could be done peer to peer. But any economics would need a central something, as would the general information about the universe... or would it?

Think outside the box.

[klauss]

Doesn't matter. It's a distributed system. If one client goes offline they just disapear from the game.

Ah... but if clients also act like servers, they will have info about the status of other ships and those things. All that would be lost. You would have to recreate that. How? That's the matter.

[chuck_starchaser]

I think monotone imagines that every client would be a server and have all of the info. This is not doable, if that's what he's proposing, because to do that, every client would have to send its own info to all other clients at every tick of the physics engine, which would take longer than the life-span of a physics frame. One of the reasons to have a server in the first place is so that on upload every client sends its own info to the server only, at each physics frame, and the server then broadcasts the compound state to every client (well, actually one chunk of the total state at a time, I suppose).

[smbarbour]

Doesn't matter. It's a distributed system. If one client goes offline they just disapear from the game. This is a bit annoying for someone who's about to blow them up maybe but it happens all the time in MMOGs and people deal with it.

I've posted a suggestion on this before. (which also goes well with chuck_starchaser's "hardcore" design IMHO)

If a client unexpectedly disconnects, the AI should control the user's ship and send it towards the nearest friendly base or planet. If the user should reconnect before the ship gets there, they will regain control of the ship. I believe that the user's presence should not vanish simply because they dropped the connection. If the user is about to die, they shouldn't be able to get out of it by intentionally dropping, but a user who loses connectivity (such as due to a power outage), should not have their player killed because of it.

[klauss]

Again: smbarbour, I was referring to loosing a server, not loosing a player. That is, loosing a sizable portion of the game's state. There should be backups, and other mechanisms to mitigate its effect.

About the doability of each client handling its own info and broadcasting it... perhaps it is doable. Kind of the chuck's event class, with subscribers. Each client would be a subscriber.

Now, how do you send all those packets without impacting in bandwidth?

IPv6

There are special provisions for advanced broadcast topologies, which includes the "subscriber" mechanism (if I recall correctly).

The problem, if that broadcasting method worked, would be trustworthyness. How would a client decide whether a packet is trustworthy or not? But, imagine you figure that out, it would be really efficient both in computational cost and in bandwidth usage, since clients comunicate between them mostly and leave the server almost out. The server would say: talk to peter, he's in your system. So the network would be partitioned, and would achieve an amazing performance level, should all the other shortcomings be compensated (trust is one, lag is the other, contingencies, blah, blah)

[Guest]

I think monotone imagines that every client would be a server and have all of the info. This is not doable, if that's what he's proposing, because to do that, every client would have to send its own info to all other clients at every tick of the physics engine...

Ah, but as klauss points out -

...The problem, if that broadcasting method worked, would be trustworthyness. How would a client decide whether a packet is trustworthy or not? But, imagine you figure that out, it would be really efficient both in computational cost and in bandwidth usage, since clients comunicate between them mostly and leave the server almost out. The server would say: talk to peter, he's in your system. So the network would be partitioned, and would achieve an amazing performance level, should all the other shortcomings be compensated (trust is one, lag is the other, contingencies, blah, blah)

This is precisely the lines along which im thinking. My client doesn't need to know the position and actions of ships in another system. In fact it probably doesnt need to know whats going on the other side of the same system, if it cant be drawn on the screen then i cant have any real-time interaction so dont need to know its precise location, trajectory velocity, etc.

Each client only need interact and communicate with those clients that it has a direct interaction with. The vision i have (for i accept it is a little far out at the moment) is a system where the game universe is partitioned with groups of clients dynamically creating sub-clusters as required. On another layer (ie trade), the client is part of a larger cluster where the data requirements are less time critical. At the top most layer, login, chat channels, missions and story lines and other coordination which require minimal processing could be maintained on community run servers.

oct

[Duality]

As for making the ship disappear when being disconnected would be a bit of a bad idea because it would encourage cowards to simple pull the plug on their network and make it disappear on purpose.

My solution to this is when a player disconnects, then his ship is now a sitting duck for anyone who wants to shoot it. The ship will disappear in 2-5 minutes after disconnection.

[ack2000]

or you could have a basic AI take control and user better pray it wins the fight.

[pontiac]

My solution to this is when a player disconnects, then his ship is now a sitting duck for anyone who wants to shoot it. The ship will disappear in 2-5 minutes after disconnection.

That would be the Quake way, no?

Ok, what about making the ship of the disconnected player invunerable and freezed (= some graphiocal identification would be needed) forever (= some realtime days) in the last position?
That way when reconnecting the disconnected player has no real advantage nor disadvantage from his disconnection.

Of course if he was involved in a fight with _human_ players they will be far away that time, but they may drop some AI wingmen (or sentrys or mines ...etc..) at the place where the ship is freezed to finish it of when the player reconnects....

Pontiac