Server Help

2dragons · Novice Joined: Feb 17 2004 Posts: 95 Offline

I've been using version 1.3.1 of your proposed protocol Grel. So all my reference is from such. Here is a list of things I propose need changed/added.

s->b PLOGIN should include a field for timezone

Support needs to be added for statistical tracking (kills/deaths/etc...)

b->s POK add stats fields
s->b PLEAVE add stats fields

or perhaps a two way message type PSTATS?

The chat system supports using the name of the chat or the number representing the chat. This introduces a problem as there is no way to differentiate between a chat number and a chat name. (ie ?chat=1) To follow this all billers implementing the TCP protocol must deny the usage of chats that are numbers.

CypherJF · Posted: Mon Dec 27, 2004 2:38 am Post subject:

Sounds okay to me. However, I haven't touched the User Database protocol lately.
_________________
Performance is often the art of cheating carefully. - James Gosling

Mine GO BOOM · Posted: Mon Dec 27, 2004 10:40 am Post subject:

Chat clients are to be chatting, not player watching. He already stated he wants to keep it simple, thus the name of the protocol.

If you'd like to create your own method of dealing with stats, feel free to add it into a command in which users can opt in or out of easily. Then you can create your own STATS:x:x:x lines for clients to handle.

Timezone isn't really needed. Can't see a practical application in a simple chat client/server protocol.

EDIT: Ignore me, thought was in a different forum, misread the title.

CypherJF · Posted: Mon Dec 27, 2004 12:51 pm Post subject:

Mine GO BOOM: I believe you've misread. 2dragons is talking about the User-Database protocol; not Chatnet.

D1st0rt · Posted: Mon Dec 27, 2004 1:49 pm Post subject:

tcp billers 4 win!
_________________

2dragons · Novice Joined: Feb 17 2004 Posts: 95 Offline

To clarify, I'm speaking of: subspace billing server protocol proposal.

Any billing protocol SHOULD support statistical tracking or it misses a huge part of a biller.

CypherJF · Posted: Mon Dec 27, 2004 2:41 pm Post subject:

I'm just wondering why does a biller need to keep track of the timezone?

Cyan~Fire · Posted: Mon Dec 27, 2004 3:07 pm Post subject:

Isn't that part of the SS validation system? Or maybe it's just handled by Subgame?
_________________
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.

CypherJF · Posted: Mon Dec 27, 2004 3:27 pm Post subject:

I guess I never really thought about it; I know subgame reports the timezone under *info or *einfo; but never really thought about why. But, why does the biller need it, and how do you verify against it..

Grelminar · Creator of Asss Joined: Feb 26 2003 Posts: 378 Offline

What exactly do you need the timezone for? It's only slightly useful for authentication/banning purposes, so I suspect you have something else in mind, but I'd like to know what it is.

As for stats, they will not go in this protocol. asss keeps track of lots of stats data in complex formats, which would be quite difficult to embed in this sort of protocol. Eventually a separate stats aggregation system might be designed, but it would be a complement to the user database system, not a component of it.

2dragons · Novice Joined: Feb 17 2004 Posts: 95 Offline

Timezone: hrm 3 little reasons

1. To keep the protocol a bit more similar to the UDP. It is quite amazing how much there is different between the 2 protocols once you get past the protocols themselves. (I'd actually like to see more changes than just this.)

2. User auth/banning, sure why not, it should be cake to include so why not include it even if it is almost not worthwhile for this.

3. Demographics. I love data and displaying data. Timezone provides a great way to divide it up. Add it in with the registration/demo form and it is nice.

2dragons · Novice Joined: Feb 17 2004 Posts: 95 Offline

Oh just wanted to add, my perspective is totally based on using the 2 protocols together. I care little for the TCP protocol by itself.

In fact what I've done doesn't take into consideratino the protocols, just the data that is similar between the 2 and that which is necessary. It easily supports a dynamic range of protocols fairly easily, but there are certain case between TCP/UDP that just suck.

ie: TCP: named server, UDP: id'd server

Grelminar · Creator of Asss Joined: Feb 26 2003 Posts: 378 Offline

As a general note, if there's a difference between the protocols, it's probably deliberate. The UDP protocol is a mess, and I was trying to get rid of as many quirks as possible.

Timezones do seem useful, so I'll add them. Before I make a non-backwards-compatible change, are there any other fields that should be added this time around?

2dragons · Novice Joined: Feb 17 2004 Posts: 95 Offline

I agree the UDP protocol is a mess, and I do like the crap you've removed when creating the TCP.

Only other change I'd say is necessary would be in regards to:

g->b CHAT

'channel is the name of the channel. alternatively, it can be a
number signifying which of the player's channels the message is
intended for.'

There is no way for the biller to know if it should be interpreted as a channel or a chat number.

CypherJF · Posted: Sun Jan 02, 2005 9:02 pm Post subject:

What would be nice is a field for the port in which the server is listening to. So then you could make a zone info page, with the zone IP/port info...

2dragons · Novice Joined: Feb 17 2004 Posts: 95 Offline

Yes I'm glad Cypher pointed that out. Port is necessary for CONNECT, precisely for what he said.

-Smong- · Guest Offline

CypherJF · Posted: Mon Jan 03, 2005 1:58 pm Post subject:

Why bother with having 2-3 scripts for say a website that you have a zone info page for every zone connected. I'd rather not have to query the directory server as well; when I could just simply store it in a DB field when the zone connects.

Also, why isn't there support for biller control for: zone reset, zone shutdown?

CypherJF · Posted: Mon Jan 03, 2005 2:20 pm Post subject:

Oh just looking over Catid's biller; and decided, I think timezone identifier would be smart to add as well.

2dragons · Novice Joined: Feb 17 2004 Posts: 95 Offline

Grel has already agreed to add timezone in.

CypherJF · Posted: Mon Jan 03, 2005 9:01 pm Post subject:

Aye! yeah, what 2d said.

CypherJF · Posted: Tue Jan 04, 2005 1:24 am Post subject:

Question, why is it when the TCP biller sends a PBAD, Chatnet receives: "LOGINBAD:???" -- Shouldn't the ??? = rtext?

Question: along the same lines
B <-> S POK:3:Welcome to the Network, we recommend you to ?setemail once you login.:mynx2::7:0:01-04-2005 01:22:47

Why doesn't the rtext field be sent to Continuum and/or chatnet... I thought it was supposed to?

And does WANTREG work w/ Continuum, or only Subspace clients?

Smong · Posted: Tue Jan 04, 2005 9:39 am Post subject:

Looking at the code rtext is ignored in POK, you can use the PENTERARENA to trigger a MSG containing the greet text.

ExplodyThingy · Posted: Wed Jan 05, 2005 5:58 pm Post subject:

The reason for the diference is simple, and the rtext in POK strikes me as useless, but it could potentially be used to singal "You are logged in, BUT..." Such text would probably be only relavant to the logs on ASSS. PENTERARENA is used so that the biller does not have to guess whether or not the player is ready to recieve messages. The risk is that after a POK, the player could read the news, the biller sends after a time delay a greeting, and the player mises it completely.

For those of you have some shady issues about the protocol such as why there is no ability to shutdown a server, much of it has been addressed back in the day by yours truely and grel boy, here:
https://forums.minegoboom.com/viewtopic.php?t=2191&
Official protocol proposals are here:
http://sscx.net/asss/new-biller-prot.txt

CypherJF · Posted: Wed Jan 05, 2005 7:14 pm Post subject:

I had wondered that myself, does ASSS not allow : in zone names...