Server Help :: View topic - *sendto and some mystery server.ini settings

Server Help

General Questions - *sendto and some mystery server.ini settings

Doc Flabby - Wed Nov 28, 2007 11:03 am
Post subject: *sendto and some mystery server.ini settings

Some more interesting stuff i dredged up. The following entries are loaded when starting subgame from subgame.ini (i've filled in examples o what i think could go in the entries)

[Peers]
MyArenas = example, example2

[Peer0]
//must include port and be valid hostname or entire entry is ignored.
Address = 127.0.0.1:1000
SendOnly = 0
SendPlayerList = 1
Password =bbbbb
Arenas = example

[Peer1]
Address = 127.0.0.1:6000
SendOnly = 0
SendPlayerList = 1
Password = fsfsf
Arenas = example2

[Peer...]
etcetcetc

The settings are loaded before anything else. Don't totally understand what these do (if anything) or mean. Anyone able to shed any light? Seems to be some kinda distributed server setting.

Cyan~Fire - Wed Nov 28, 2007 11:59 am
Post subject:

Mmm there's always been a rumor TW works on a distributed server network.

Doc Flabby - Wed Nov 28, 2007 1:25 pm
Post subject:

On another note I've found the correct syntax for *sendto

As was thought it sends a player to another zone

example usage /*sendto zone ip, zone port

Code: Show/Hide

/*sendto 127.0.0.1,6000

I've tested this on my computer and it works. I'm running the latest public version of subgame

CypherJF - Wed Nov 28, 2007 7:47 pm
Post subject:

Sweet! I echo the same sentiments, I've always heard TW runs on distributed network as well. If these settings/commands work, it makes it even more probable.

Cyan~Fire - Wed Nov 28, 2007 11:42 pm
Post subject:

Nice stuff.

Maverick - Thu Nov 29, 2007 3:00 am
Post subject:

Haha still hex editing continuum .exe file's, doc?

Doc Flabby wrote:

I've found the correct syntax for *sendto

Sweet, good work on finding out

About those [Peer] settings, have you got them working already?

Those are some interesting settings, I wonder they do.
SendOnly, SendPlayerList, Password, Arenas ... hmmmm

D1st0rt - Thu Nov 29, 2007 2:10 pm
Post subject:

I actually talked with Dock about sendto years back, he said they run a single instance of subgame and that it's used to redirect players when they're being DDoS attacked

dugwyler - Thu Nov 29, 2007 6:40 pm
Post subject:

Found out that the full syntax is:

*sendto IP,port,arenaname

You can send them to a given arena, or use it at the edge of an arena map and send someone to the next one in an RPG-style game, etc!

Maverick - Thu Nov 29, 2007 6:42 pm
Post subject:

Awesome

Too bad it's sysop only

You can actually send people to different arenas in the same server $$

Doc Flabby - Thu Nov 29, 2007 7:16 pm
Post subject:

This discovery opens up alot of new ideas for zones

Dr Brain - Thu Nov 29, 2007 7:58 pm
Post subject:

Nothing that ASSS couldn't already provide.

dugwyler - Thu Nov 29, 2007 10:59 pm
Post subject:

Hey, get Priit to run it and we're on board. In the meantime, I'll be ridiculously happy over small miracles such as this.

Cheese - Fri Nov 30, 2007 12:21 am
Post subject:

Maverick wrote:

Too bad it's sysop only

nothing mervbot cant handle =)

Maverick - Fri Nov 30, 2007 1:53 am
Post subject:

Cheese wrote:

[..]
nothing mervbot cant handle =)

You're forgetting that even the bot has to have sysop.

I meant it more like "too bad it's sysop so normal staff can't use it on a daily basis to use against players who are breaking rules".

Anonymous - Sat Dec 01, 2007 1:41 pm
Post subject:

just tried it from SSCI Mystic Kingdom to Trench wars, works but the map is redownloaded and saved in the original zone file.
Good stuff

cycad - Sat Dec 01, 2007 6:49 pm
Post subject:

Hi I don't know if this is useful to this group (I don't follow these forums and was linked to this topic) but the format of the packet that *sendto uses is:

Code: Show/Hide

#pragma pack(1)
typedef struct s2c_sendto S2C_SENDTO;
struct s2c_sendto {
BYTE type;       // 0x3B
DWORD ip_addr;    // IP Address (little endian)
WORD port_num;    // Port number (little endian)
WORD join_type;    // Same as the arena login packet
char arena_name[16]; // Arena Name
DWORD unused;
};
#pragma pack()

I haven't had any luck testing *sendto locally though, maybe because the target of my testing isn't connected to the SSC biller. Just guessing.

Also, I'm mildly confident that the INI settings mentioned here don't pertain to *sendto.

Smong - Sat Dec 01, 2007 7:47 pm
Post subject:

Your unused field is marked as "loginid" in asss. I never got it to work in asss anyway.

Anonymous - Thu Dec 06, 2007 12:29 pm
Post subject:

this doesn't seem to work pub to pub

anyone have luck sending a player to a public arena?

Animate Dreams - Thu Dec 06, 2007 2:28 pm
Post subject:

I sent myself from SSCI Penis to SSCI Halo multiple times. Pub to pub.

Samapico - Fri Dec 07, 2007 12:00 am
Post subject:

Does it require sysop in both source and target zones?
Does it work from arena to arena in a same zone?
I tried it and couldn't get it to work

rootbear75 - Fri Dec 07, 2007 12:45 am
Post subject:

Anonymous wrote:

this doesn't seem to work pub to pub

anyone have luck sending a player to a public arena?

wouldn't you just do /*sendto <IP>,<port>,# to send someone to Public #
ex: /*sendto 127.0.0.1,6000,32 to send someone to public 32

Maverick - Fri Dec 07, 2007 2:04 am
Post subject:

/*sendto IP,Port will send you to a public arena, so it also works pub to pub.

Samapico wrote:

Does it require sysop in both source and target zones?
Does it work from arena to arena in a same zone?
I tried it and couldn't get it to work

It requires sysop to do the command, however the target doesn't need to be sysop to be switched.
It works from arena to arena in the same zone, you just need to use the IP and port of the current zone.

Samapico, check the server.ini DisablePvtCommands setting. It might have been disabled as it's possible to crash subgame with it.

Note; if you login to sysop or smod using password*staffpassword then this command wouldn't work as you would be trying to login to the other zone using the same password*staffpassword combination.

Samapico - Sat Dec 08, 2007 12:57 am
Post subject:

Quote:

Samapico, check the server.ini DisablePvtCommands setting. It might have been disabled as it's possible to crash subgame with it.

good call...

Quote:

It might have been disabled as it's possible to crash subgame with it.

Is there any 'what NOT to do' guidelines yet?

Quote:

Note; if you login to sysop or smod using password*staffpassword then this command wouldn't work as you would be trying to login to the other zone using the same password*staffpassword combination.

oh... interesting

Animate Dreams - Sat Dec 08, 2007 11:55 pm
Post subject:

Maverick wrote:

Note; if you login to sysop or smod using password*staffpassword then this command wouldn't work as you would be trying to login to the other zone using the same password*staffpassword combination.

Er, I can see why that would happen, but it didn't happen to me. I was able to send myself from a zone I logged in with the password*sysoppassword combination into another zone I didn't have staff powers in.

milosh - Sun Dec 09, 2007 4:10 pm
Post subject:

Animate Dreams wrote:

[..]
Er, I can see why that would happen, but it didn't happen to me. I was able to send myself from a zone I logged in with the password*sysoppassword combination into another zone I didn't have staff powers in.

He's just saying that you won't be able to send yourself back to the original zone once you get there(since you won't have sysop powers in that zone).

CypherJF - Sun Dec 09, 2007 7:33 pm
Post subject:

Why would anyone think it would let you have sysop privileges in the transferred zone? That'd be a huge security risk.

milosh - Sun Dec 09, 2007 10:11 pm
Post subject:

you tell me

Blocks - Mon Dec 31, 2007 1:13 am
Post subject:

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 - Mon Dec 31, 2007 9:25 am
Post subject:

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

Animate Dreams - Mon Dec 31, 2007 8:24 pm
Post subject:

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 - Tue Jan 01, 2008 11:41 am
Post subject:

Blocks wrote:

Think there might be some client command that does this without directions from the server?

There must be but people like Mr.Ekted and MGB should know better.

Remember, Mr.Ekted made the menu interface seperate of the Continuum client. When clicking "PLAY" in the menu this seems to trigger another part of the Continuum client to start connecting to the server and logging in.
The *sendto command seems to bypass the menu interface and makes the continuum client connect to a different server directly.

Nonetheless, it's possible that no support (like a command) for this was ever created.

Mine GO BOOM - Tue Jan 01, 2008 7:03 pm
Post subject:

Maverick wrote:

There must be but people like Mr.Ekted and MGB should know better.

I made this request back a long time ago for Continuum while it was still council-only. Priit said that ?zone won't switch zones like Subspace, as that is a possible point of fast-quitting and can also use it to trick users into switching into zones they wouldn't want to go into (sort of like how jerks like to trick new people using ?go).

Cheese - Wed Jan 02, 2008 11:37 pm
Post subject:

milosh wrote:

[..]
He's just saying that you won't be able to send yourself back to the original zone once you get there(since you won't have sysop powers in that zone).

unless they have the same sysop pw

Anonymous - Sun Jan 06, 2008 12:14 am
Post subject: Not enough...

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

Animate Dreams - Mon Jan 07, 2008 8:29 pm
Post subject:

Mine GO BOOM wrote:

[..]

I made this request back a long time ago for Continuum while it was still council-only. Priit said that ?zone won't switch zones like Subspace, as that is a possible point of fast-quitting and can also use it to trick users into switching into zones they wouldn't want to go into (sort of like how jerks like to trick new people using ?go).

That's a good point, but I'm sure it could be coded in such a way that fast-quitting was impossible with that command, and I don't care so much about the latter. To my knowledge, tricking players with ?go is completely harmless(except in HS when it crashed the zone), I imagine a ?zone command would be just as harmless.

CypherJF - Mon Jan 07, 2008 9:37 pm
Post subject:

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 - Mon Jan 07, 2008 10:35 pm
Post subject:

Or make it valid only from spec

Cheese - Sun Jan 13, 2008 12:15 am
Post subject: Re: Not enough...

Skywize wrote:

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

if checking is on...

....we need more wizard smileys >:D

and it would be awesome if i could use ?zone to go places...

BDwinsAlt - Sun Jan 13, 2008 2:37 pm
Post subject:

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 - Sun Jan 13, 2008 2:49 pm
Post subject:

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 - Mon Jan 21, 2008 1:33 am
Post subject:

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 - Tue Jan 22, 2008 6:24 pm
Post subject:

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 - Sun Jan 27, 2008 12:05 am
Post subject:

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. - Fri Aug 01, 2008 2:46 am
Post subject:

Quote:

Some more interesting stuff i dredged up. The following entries are loaded when starting subgame from subgame.ini (i've filled in examples o what i think could go in the entries)

I hate to revive an old topic, but does doc flabby mean server.ini?

Doc Flabby - Fri Aug 01, 2008 5:53 am
Post subject:

ya it should be server.ini its another of my famous typos -_-

numpf - Sun Feb 22, 2009 8:17 pm
Post subject:

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 - Mon Feb 23, 2009 2:29 pm
Post subject:

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 - Tue Feb 24, 2009 3:55 pm
Post subject:

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 - Wed Feb 25, 2009 12:44 pm
Post subject:

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 - Wed Feb 25, 2009 6:54 pm
Post subject:

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

numpf - Fri Feb 27, 2009 8:06 pm
Post subject:

grel asked him how peering works for SG so grel could do it in asss. He just sent the files for the PeerManager class to grel with some extra notes, because there's nothing sensitive in that class and it's the most efficient way to communicate the details of the protocol (timeouts, retry counts, etc). I have it because I was going to implement it before we discovered the pwd problem.

-numpf

Doc Flabby - Fri Feb 27, 2009 10:13 pm
Post subject:

This might be of interest Snrrrub has done some research in this area

http://docs.google.com/Doc?id=d67vd23_50gcs8wzdk

All times are -5 GMT
View topic
Powered by phpBB 2.0 .0.11 © 2001 phpBB Group