Server Help

[CypherJF]

they're hogging the wealth - go figure. doesn't surprise me though .. i doubt 1 subgame would have been able to hold 800 people on at one time.. heh. anyways im off to bed. nite all
_________________
Performance is often the art of cheating carefully. - James Gosling

[Cerium]

Does the client even support that? It seems like itd need a router on the frontend to allow different servers to process each arena...

And even still... wouldnt that require another login exchange each time you change servers? If it doesnt, isnt that prone to spoofing an ops name?

Details... damnit!

[50% Packetloss]

Prittk probably has all of the subgame source code, so I imagine that he worked out any issues with passing players to other servers. Then again, maybe subgame is capable of supporting hundreds of people as long as the server computer has sufficient speed and memory to support it.

[Grav@work]

VIE SubGame supported upto 300~320 users at a "stable" status, AFAIR, correct me if I'm wrong MGB, though I cannot remember if it was in relation to the entire zone or arena.
But that was the specific Jeff gave back in the day.


Cerium, every (korean) MMORPG uses this technique, I don't see the problem of SS using it as well.


As for timer, most likely same timer that is being tracked at Infantry.
System timer? bios? Used to search for overclocking/unsync packets/speed hacking?
Beats me really.
Instead of beating the bush of underknowledge, I take the direct approach and go ask Priit, see if he ever care to answer.

[Cerium]

Im not saying its not possible, im wondering how its done and if its secure. The protocol was never designed to support such a thing.

Also, I would assume the limit per arena is 255, since the position packet sends the player ID as 1 byte... anything beyond 255 players would start duplicating IDs or sending invalid positions.

The timer doesnt seem to mean much of anything to me. I checked it 5 times in a row as fast as my dialup connection could send the packets... each value varied by huge degress and increased and decreased at seemingly random rates.

[Maverick]

I wonder if there is a protection against having more then 255 players in one arena because it might crash the server if that happens (if it ever does).
_________________

Nickname: Maverick (I changed my name!)
TWCore developer | Subspace statistics

[Cerium]

I dont think the server would crash.

A few years back in DZ pub, I ended up getting the same ID as another guy who was playing at the moment... Server didnt have any problem... the client (and TestTube who was smod/sysop at the time) did.

Whenever the other guy made a kill, I got a kill and whatever points he got and my bty went up by 30. But when he died, nothing happened. Whenever I saw the other guy, his ship constantly cycled between the one he was using (jav) and the one I was using (lev). I dont know how it looked to everyone else, but he appeared to be firing L3s whenever he bombed. Anyway, in a matter of all of a minute or two of sitting in safe leeching points, I had a 5k bty and a perfect 60-0 or so. TestTube assumed I was cheating and banned me...

Moral of the story: I dont think the server would choke, but it sure as hell would have some side effects.

[-Smong-]

There are two s2c position packets, one of them supports 16bit player id's and 16bit bounties.

I remember reading about having one zone on multiple subgame2's, but couldn't find anything about it in whatsnew.txt when I had another look, maybe it got edited out.

I doubt the *sendto command has anything to do with it as that would imply needing a bot to message people in order to manage the server load.

[Cerium]

Really? How do you tell the difference between the two? Checking for an extra 2 bytes could (will) get confused with a smaller position with energy.

[Smong]

Every packet has an type number, there are two different types for s2c positions, 0x5 and 0x28.

[Gravitron]

Cerium the uber hacker.

How it's being done?
The biller ties subgames together.
Koreans do it in a four server format (1 extra, for current SS - dr.brain's zone could use it, a character DB server).
A main hub server connects between the billing server and the zone server with the aforementioned Char-DB (download and analyse helbreath for a good example of it).
Example:
Central Account Database that share its info with different Zone Server(s).
The Zone Server act as a mutual hub for all the different Arena Server(s) that form up the zone.
So you have, always, one biller, so to speak.
Then you have 5 (for sake of argument) subgame-managers.
Each subgame-manager has its own several subgame-arena servers (IE the zone is split onto different hosting, each takes an arena or two or whatever).


Is it secure?
Though I have no knowledge, theory would suggest, absolutely not.
Unless you'll be employing some kind of a high bit encryption or whatever.
As Catid said to me once, biller and zone server need to be the same, when you split up the functionality, you inherently damage security.

Although, as long as you are running all servers from the same machine (which causes a huge burden and kind of beat the purpose, no?) and those with access you trust, it wouldn't be more insecure than as it is now.
Still, at the end result you can divide each server, or host all but the actual zone ones at the same spot, and have the various arenas/zone themselves hosted across other servers.
Which isn't really different than the way biller connects all zones together.

Bottom line, though:
Since subspace is not a MMORPG, and you can't nor need to tie up one arena after another or add "maps" to an arena, there is no use for having different arenas (which are not meant really to be different from the main zone/pub anyway) as it stands now.
Having running a central biller and various zones to choose playing from is good enough and is just the same.
The only use would be to take all SVS zones, superzones, misc/junk zones, and put them under a main zone title, then the actual games as arenas, inorder to clean the clutter at the directory server and make it easier for a player to pick his favorite gaming style.
And there, you would need different servers to host the arenas to lighten the burden.



BTW, (unless you already know for certain what it does) *sendto might be used as mentioned above to move players from a zone to another, the way MMORPGs move you from "map world" to another, not arenas.
Perhaps Priit had the insight to look onto future, more enticing, features.
(nonetheless, banning a player onto a cellblock/duelbox arena would be fun ).
I know Infantry already has (or had planned) a system for deploying a level ojbect on the map to move a player from one zone to another (virtually creating a MMORPG world in a sense, or some extreme CTF style battlefield).
And both INF and VIE SubSpace clients supports a ?zone command that allows the player to change zone (so it is inherenitly built-in, just needs to add a server-side command to trigger its use and supply parameters).


P.S.
Another undocumented, yet well known, command is the *points (sysop I believe).

[CypherJF]

*points It's documentated on MGB's server help site on the commands list. But an interesting thought about the sendto actually moving a player to another server...

Maucaub said that transfering a continuum from one zone to another has been built in already - just it's not used. He had asked us our thoughts on it: good, bad, and ... the ugly.

hm interesting thoughts though.

[Cerium]

You mean 0x05 =)

At first I thought there was a 2nd position packet (rather than the weapon fired packet).
Was wondering why I never received an unknown in my logs...

[Smong]

[D1st0rt]

is that how they can handle 600+ people without massive lag?
_________________

[Gravitron]

That and the fact that they are not C&W.
Different routing to their servers, less load on thier host bandwidth.

[Night_Fox]

Oh is that causes a packet.log?
History dump?

[D1st0rt]

After talking with DoCk> about it, he said it was used for when they kept getting DoS attacked. Once a player logged in, they would get redirected to the real server so it didn't fall prey to a script kiddie.

Apparently they support high populations with mysterious things called "Threads"

[Donkano]

A topic over a year ago being brought up again? Wow.

[Muskrat]

I found it a pretty significant and interesting contribution. Don't get cynical.

[Mr Ekted]

[Cyan~Fire]

Each player runs in its own thread! That cuts the processing time required greatly!
_________________
This help is informational only. No representation is made or warranty given as to its content. User assumes all risk of use. Cyan~Fire assumes no responsibility for any loss or delay resulting from such use.
Wise men STILL seek Him.

[Maverick]

[Mr Ekted]

Threads help you in two circumstances:

1. You have more than 1 processor. Each thread can potentially be running at the same time.

2. Your threads are making lots of blocking calls (waiting for disk I/O, etc), so they won't slow down other threads.

Having a thread per user is just a cop-out. It lets you write procedural code (rather than event-driven), but then a ton of time is spent thread switching. There's almost no case where a thread per user is going to be better than "flat", unless your language or operating system is handicapped.

[D1st0rt]

Well, the previous idea in the topic was that they had multiple subgames. I assume that with one subgame and 700 players they would have to have some sort of threading, but probably not for each player as the sarcastic Cyan suggests. I would think one per arena would probably be reasonable though.

Donkano, you are guilty of what you accused me for because you didn't contribute anything so please refrain from talking.