Server Help

[CypherJF]

Why would anyone think it would let you have sysop privileges in the transferred zone? That'd be a huge security risk.
_________________
Performance is often the art of cheating carefully. - James Gosling

[milosh]

you tell me
_________________
SSCU Trench Wars Moderator
SSCU Trench Wars Bot Developer
SSCU Trench Wars Dev Member

[Blocks]

Any idea if this feature is accessible from the client side? What I mean is, when you /*sendto someone, the server is telling them to go somewhere else ... it's the client that is actually going to the new zone. Think there might be some client command that does this without directions from the server?

[Bak]

nah, you can't really send data to other players without going through the server. unless you're staff, you don't even who where to send it (their ip address)

unless you meant doing it to yourself... in which case, I dunno
_________________
SubSpace Discretion: A Third Generation SubSpace Client

[Animate Dreams]

He probably meant doing it to yourself... which would be really nice. But I've never successfully sent myself from one server to another. I was only able to send myself from one SSCI zone to another. As strange as it seems, it makes me think the server has to do a little bit more than send the information to the client. As to what else it would be doing, I'm clueless.

[Maverick]

[Mine GO BOOM]

[Cheese]

[Skywize]

Just having the sysop password isnt enough. You have to also be on the sysop.txt file.

[Animate Dreams]

[CypherJF]

Why won't ?zone be setup in the way that you can't leave the zone until your energy is what 3/4th? completely full? or a 10 second delay? It's doable. If people wanted to cheat, they'd just task manager and kill the process.

[Samapico]

Or make it valid only from spec
_________________
(Insert a bunch of dead links here)

[Cheese]

[BDwinsAlt]

I remember that duck duck guy had a biller that would log you back in with another name into the same zone. I'm not sure how he got the client to do that. It was like a ?switch command or something. You could login to your other accounts.

[CypherJF]

The UDP biller protocol allows a biller to connect a client to a zone. ASSS ignores such a packet by default. It would make sense for a biller to "relocate" players if a zone was going offline?

[Arnk Kilo Dylie]

The redirect protocol may not be done correctly by asss. I did some experimenting with this before to allow HZ some ?go reconnect and ?go otherzone options, with no feasible success.

asss generally will not accept redirected clients because redirecting appears to not involve having the client send ANY password (imagine the security risk if it did,) and as far as I can remember it will not be accepted by subgame zones either. So I wonder if that UDP biller packet you are talking about is also involved (so that the server knows who to allow in without a password, as the biller would be telling them.)

[CypherJF]

Actually, I'm mistaken.

Looks like process_userpkt was re-enabled by default in 1.4.4.

Code: Show/Hide 868,870c868 < #ifdef CFG_ALLOW_BILLING_USERPKT < /* this doesn't look like a good idea to me... */ < local void process_userpkt(const char *data,int len) --- > local void process_userpkt(const char *data, int len) 881a880,883 >    { >       /* send to all players not allowed */ >       lm->Log(L_WARN, "<billing_ssc> b2s user packet filtered (target all)"); >       /* unlikely to get this, maybe during score reset? 882a885,886 >       */ >    } 885a890 > 887c892,908 <          net->SendToOne(p, pkt->Data, datalen, NET_RELIABLE); --- >       { >          /* only allow S2C_LOGINTEXT for banned players to get the ban text. */ >          if (*pkt->Data == S2C_LOGINTEXT) >          { >             net->SendToOne(p, pkt->Data, datalen, NET_RELIABLE); >          } >          else >          { >             lm->Log(L_WARN, "<billing_ssc> b2s user packet " >                "filtered (target [%s])", p->name); >          } >       } >       else >       { >          lm->Log(L_WARN, "<billing_ssc> b2s user packet " >             "unknown pid (%d)", pkt->ConnectionID); >       } 889,891d909 <    lm->Log(L_DRIVEL, "<billing_ssc> [pid=%d] " <          "user data packet from billing server, %d bytes", <          (int)pkt->ConnectionID, len); 893d910 < #endif 973d989 < #ifdef CFG_ALLOW_BILLING_USERPKT 977d992 < #endif

[Arnk Kilo Dylie]

After some experimenting with two subgames and a subbill, and then a subbill, subgame, and asss (for tracking incoming billing stuff) I couldn't find any evidence of the biller giving hints to asss about incoming /*sendtos. Then again I couldn't even get the two subgames to send between each other (failed login by incorrect password because it's blank.)

Anyway, props to be had for whoever figures out exactly how this works such that asss can replicate it.

[L.C.]

[Doc Flabby]

ya it should be server.ini its another of my famous typos -_-
_________________
Rediscover online gaming. Get Subspace | STF The future...prehaps

[numpf]

I wrote these notes on peering a long time ago when we were considering implementing peering with asss. They are not official in that they are old and I wasn't able to get a test setup working. That appears to have been due to a redirect issue that's being worked on/fixed.

I would be interested in hearing if these are accurate.

---

Subgame Peering

Go request (GR) definition:
Any time a client asks to go to a new arena. In Cont, when a zone is first entered, it asks to go to a NULL arena (i.e. no arena name is given). This is the same as typing "?go" in subgame (no arena name). Other clients (bots, chatnet clients, etc.) can and do sometimes ask to go to specific arenas on zone entry.

server.ini sections:
[Peers]
MyArenas=<ARENA SPEC>
// see below for ARENA SPEC

// maximum number of peers is 8 and # starts at 0: Peer0, Peer1, ... Peer7
[Peer<#>]
Address=127.0.0.1:5000
Password=testpw
// passwords explained below
Arenas=<ARENA SPEC>

<ARENA SPEC>: A comma-separated list of arena names to match. It may not be longer than 511 characters. No more than 32 different arenas may be given. No whitespace is allowed, unless it's meant as part of the arena name. 2 special arena names are recognized, "$pub" and "$pvt". $pub matches any time no arena name is given in a GR. $pvt is the converse of $pub; it _always_ matches unless no arena name is given.

GR Matching:
When a GR is issued in a zone (or more accurately, subgame instance), it first consults the list Peer:MyArenas, if it exists. If a match is found, the GR is processed normally (as if there were no peers). The purpose appears to be for use with $pvt. If you have a $pvt rule in a [Peer<#>] section to send people to another zone whenever they go to a named arena, this acts as a mask, a list of the arenas you explicitly want this subgame instance to manage.

If no match is found in Peer:MyArenas, each Peer<#>:Arenas list is consulted in order (by number, not the order they appear in the file). On the first match found, the player is transparently redirected to the address for that peer. Note that the arena name will be part of the initial GR issued when the client enters that zone. If after consulting all available peers no match is found, the request is handled normally.

Passwords:
If you decide to have 2 subgame instances peer, they must agree on a password. The password must agree in each INI [Peer<#>] entry which refers to the other zone.

Example: 2 zones running on localhost, subgame-A on port 5000 and subgame-B on port 7777

in subgame-A's ini:
[Misc]
Port=5000
...

[Peer3]
Address=127.0.0.1:7777
Password=hackme


and in subgame-B's ini:
[Misc]
Port=7777
...

[Peer1]
Address=127.0.0.1:5000
Password=hackme

[numpf]

When a client is redirected to a non-SSC zone it sends a null password, so redirects will not work (unless you run a modified server that accepts null pwds). Other parts of this should still work; you can probably share arena lists (iirc I got that part working), and redirect from your non-SSC zone to SSC zones. Some asss SSC zones (HZ PB and maybe HS) currently can't accept redirects, but this appears to be a billing-flag issue, as at least one other stock asss SSC zone accepts redirects.

-numpf

[Cheese]

thanks numpf, quite helpful

also, it looks like you switched 'if a match is found' with 'if no match is found'...
or is that correct?

also, how do SendOnly and SendPlayerList work?

[numpf]

It was correct but poorly phrased. I have edited that section to be less poorly phrased. The notes are essentially a translation of src to english, hence the "if" chain. My notes are based on priitk's src for this part of subgame. They are dated 2005-12-21, so they are likely out of date. I see nothing about SendOnly and SendPlayerList in my files.

According to Snrrrub, SendPlayerList controls whether you want to broadcast your list of players to your peers. This sounds accurate. Subgame uses the player list to avoid sending a request to billing when someone uses ?find on a player who is in a peered zone.

SendOnly could have something to do with *zone and ?alert messages. Both of these are sent in the peering protocol. SendOnly could be a boolean saying you don't want your instance of subgame to broadcast *zone and ?alert if they come from other peers, or an enum for various combinations. This should be easily testable. It could also have something to do with the sending of private (#-prefixed) arena names. edit: it could also be an <ARENASPEC>, to send player lists for only matched arenas.

As a note to snrrrub or anyone else, the 03 unknown in his document is for ?alert messgaes. I don't have the format, but I would assume it contains the player, arena, and msg. If that first byte is really not part of the msg, possibly public arena number, or a flag toggled by SendOnly.


-numpf

[Cheese]

how on earth did you manage to get a copy of priits src...?