Server Help

[ExplodyThingy]

EDIT: A link to the original TCP protocol proposal by grelminar: https://forums.minegoboom.com/files/new-biller-prot.txt

Here is my little proposal on the tcp billing protocol. Ive noticed that there are potential flaws and room for improvements. Abbrvs: c-client, g-game server,b-biller. I am unfamiliar with TCP and perhaps some ideas might be relic of the s->c/c->s system, specifically with the next 2 or 3.

g->b/b->g TERM:[rtext]
Kill signal. Equivalant to g->c/c->g 0x0007. Good for a guage when someone dies.

g->b/b->g PING:[timestamp]
g->b/b->g PONG:[timestamp]
Checks if either side has died. If the server crashes or there's a power failure, thre will never be a TERM signal.

Apparently some implementations cant handle the self-contained ability of TCP to check whether the connection exists.

g->b PAE:pid
Player Arena Enter. When said player has fully entered first arena. Occurs simultaneous to g->c 0x31. Its known that intro messages, "you have ?message..." and other such things often get lost when the biller tries to guess when the player enters arena. Things like the updated news defiantely throw off the guessed time.

g->b REG:....
Registration form data. According to catid:

Code: Show/Hide    /* -Field Title-   -Offset-   -Length-   -Comments-     * UserID         1         4         Zone ID     * Name            5         32     * Email         37         64         Twice as long as Name     * City            101         32     * State         133         24         Odd length     * Sex            157         1         'M' / 'F'     * Age            158         1     * Home            159         1         1(TRUE) / 0(FALSE)     * Work            160         1         1(TRUE) / 0(FALSE)     * School         161         1         1(TRUE) / 0(FALSE)     * Processor      162         2         ie. 586     * Unknown         164         6         WTF are these for?     * Hostname         170         80         Should this be used in HID?     */

g->b/b->g ERROR:type:string
Server errors. Not necessarily log data.

g->b/b->g PKILL:pid:[rtext]
Replaces PLEAVE. Used bi-directionally to disconnect a player.

b->g SHUTDOWN:[time]
Remote shutdown, in the event the login is b0rked. Usually used in global scoreresetting, but since that task has changed its not needed. The Time is used for a recycle, and if non-zero doesnt attempt to reconect to the biller for said amount of time. This can be used for billing updates in which downtime of 30+ seconds can be expected.

A fault with the POK: packet. The date contains colons, which is the parse character. And form of extention on the packet could seriously fuck up.

Naming convention:
CONNECTOK:billername
The biller name should be named with SOFTWARE:VERSIONSTRING:VERSIONINT. Since extra colons are not nesecarily bad, this shouldnt hurt. A strictly numeric version number will allow for a check to make sure that you can only connect to version X and above/below. SOFTWARE should refer to ExplBill, POCoB, SubBill, version string should be 0.0.4b, numericall 0x00 00 00 04 02
_________________
There are no stupid question, but there are many inquisitive idiots.
Loot

Dr Brain> I hate clean air and clean water. I'm a member of Evil Conservitive Industries

[Grelminar]

Thanks for the suggestions. I updated my billing module and protocol spec based on what I liked from them, but there are a few more things I want to change, so I'm not ready to publish an updated spec yet.

Specific comments:

As I mentioned, TERM is unnecessary because you really can tell when the other side disconnects through your tcp interface. If you want to catch network partitions and hard crashes, you'll have to do your own keepalives, and a PING message is a good idea. PONG is unnecessary since tcp does acks for you.

PAE is a good idea, except I renamed it PENTERARENA.

The registration stuff is a little complicated. Currently I think there's no way to register a new name using continuum, asss, and a tcp biller, and following the spec (it's missing a way to return the correct code to make cont send a new name request). And if you can't register a new name, the registration data is sort of irrelevant. I'd like to fix that situation before I add more message types to handle registration data.

ERROR is unnecessary, just use LOG. We might as well establish a convention that the text to a LOG message is in asss standard log format, which includes a severity level already.

I'd rather not have the billing server able to disconnect players at random, so I disapprove of PKILL.

Also I think SHUTDOWN is unnecessary. No asss server is going to shut down just because the biller thinks it should. The retry time is an interesting idea, but I think I'd prefer to keep things simple, and let the server retry connecting to the biller on its own schedule.

Yes, that's true about POK. Somewhat unfortunate, although it's probably not so bad because future protocol revisions don't have to be backwards compatible (although I'll try to if I can).

About the CONNECTOK thing, my updated spec has separate fields for a software name string (including software version number), and a biller network name. I also clarified the spec with regard to protocol version negociation (basically, there is no negociation: the server asks for one version, and the biller says yes or no). Software version numbers are informational only (unlike protocol version numbers), so they go in the same string as the software name.

[Dr Brain]

[ExplodyThingy]

PKILL should at least exist in the b->g direction. There nust be a way to enforce bans, whether its because of ^banned, or because of newly activated bans. If the biller has the authority to rename, why cant it disconnect?

Registration can be triggered in the old VIE client. And of course it can also be triggered in other clients such as chat clients and other goodies. Of course we dont have to ask for the same data as the old form, but we can set a convention for a new system. Granted, we can still do ?setemail and ?setname, etc etc.

Edit; SHUTDOWN reconsidered, and BROADCAST: takes care of the last thing it could possibly be used for.

[Grelminar]

Banning is an authentication thing, and doesn't necessarily have anything to do with their current session. If you want to ban someone, you can use biller commands to do that. The next time they log in, the biller will say they're not allowed to connect. And then if you want to kick them off of their current session also, you can ?kick.

Having said that, I realize letting the biller commands kick people is more convenient, so I might reconsider that position.

Um, why would registration work differently in the vie client as opposed to continuum? The problem is that to get the client to send the new name request, you have to return a certain value as the login result, and my billing module doesn't ever do that.

I'll try to fix it in a reasonable (although probably not backwards-compatible) way.

[ExplodyThingy]

Thanks for putting up with me, but Im sorry, maybe I have a misconception about the login process.

c->g (login)
g->b PLOGIN:...
b->g POK:pid:NewPlayerFlag:....
g->p (RegForm)
p->g (RegFormData)
g->b REG:....

If using PBAD:

c->g (login)
g->b PLOGIN:...
b->g PBAD:NewPlayer_RequestRegForm
g->p (RegForm)
p->g (RegFormData)
g->b REG:....
g->b PLOGIN:...
b->b POK:...

The statement about using the VIE client was that you can trigger the registration form on older clients on zones not on SSC. Therefore, youre chatnet, game clones, and what have you can alll potentially support a registration.

Additional proposal. (Im thinking of this as I go, if you missed that.)
FASTCHAT : pid : number : string
Acts like a combination process of CHAT + CHATTXT, prevents the two-part step form being necessary.

[Grelminar]

What are those exchanges supposed to represent? Certainly not anything in the current (1.22) version of the protocol...

Neither the POK or PBAD messages have a way of saying "account doesn't exist, turn on the new player flag and retry".

Also note that the registration data has nothing to do with the process of creating a new named account. It's an optional additional step.

[Grelminar]

Ok, I have a new version of the protocol spec, hopefully accommodating all these suggestions. Or at least the ones I like.

http://sscx.net/asss/new-biller-prot.txt

(And that url will always have the newest version.)

I've also updated the asss module that speaks this protocol to work with the new version. It's in cvs now, and will be in the next released version.

[-Smong-]

Finally this makes sense:

Code: Show/Hide g->b: "PLOGIN:pid:flag:name:pw:ip:macid:contid"     flag is 0 for a normal login, 1 for "i want to create a new player". # New in 1.3.1: b->g: "PBAD:pid:newname:rtext"     newname is 1 if the requested name doesn't exist in the biller's

[2dragons]

[quote="ExplodyThingy"]The statement about using the VIE client was that you can trigger the registration form on older clients on zones not on SSC. Therefore, youre chatnet, game clones, and what have you can alll potentially support a registration.[quote]

Um, you can trigger the registration form on Continuum to zones not on SSC.

[Explody]

I suppose its possible. I asked around with those who were familiar with the protocol, they said the way to successfully trigger it on Continuum via the UDP protocol was to make it look like the zone was on SSC. This is the same as disabling the "not on ssc, theyre gunna steal your password, dont go here" message that comes up. Apparently its somehow linked with the IP of the biller, im not too clear. All I was able to deduce was that it was out of my league, that others had tried unsuccessfully, and that I wouldnt know where to start.

[2dragons]

I'll pop my zones up with my biller running on it. Try registering a new name.

2dragon's TDD Biller Testing #1
2dragon's TDD Biller Testing #2

[Smong]

I'm taking it you're not going to tell us how it is done? Or is it blindingly obvious?

[2dragons]

Well personally I didn't do anything special to get it work aside from doing my best to emulate SSC Billing. So I'd say blindingly obvious as I'm no expert in the protocol.

I also thought I may have been thinking of something else so I was going to keep it to myself while I was unsure if we were on the same topic.

[Cyan~Fire]

You sure you're talking about the registration form, not the little window that pops up that says "This name doesn't exist, would you like to create it?"
_________________
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.

[2dragons]

Test it out:

2dragon's TDD Biller Testing #1
or
2dragon's TDD Biller Testing #2

[ExplodyThingy]

2d is right. 5 windows to got through:

Not on SSC
New Name
Demographics
New News
News itself