Difference between revisions of "TCP Billing FAQ"
From ASSS Wiki
(Adding some notes and precautions) |
m (→Are there any TCP billers available for public download?: +sius) |
||
| (2 intermediate revisions by the same user not shown) | |||
| Line 14: | Line 14: | ||
* [[SkyBill]] written by [[User:Doc flabby|Doc Flabby]]. | * [[SkyBill]] written by [[User:Doc flabby|Doc Flabby]]. | ||
* [[UBill]] written by [http://braddavis.info BDwinsAlt] is available at http://forums.minegoboom.com/viewtopic.php?t=7543. | * [[UBill]] written by [http://braddavis.info BDwinsAlt] is available at http://forums.minegoboom.com/viewtopic.php?t=7543. | ||
| + | * [[Sius]] written by Hakaku is available at http://forums.minegoboom.com/viewtopic.php?t=8691. | ||
<!-- | <!-- | ||
== Are there any TCP billers online for public use? == | == Are there any TCP billers online for public use? == | ||
| Line 24: | Line 25: | ||
* For starters, the protocol makes extensive use of player identification numbers rather than names. This can be a nuisance when requiring the player's name for communication between, for example, different zones and databases. Try to effectively find one or multiple solutions to store the player id along with their name for quick and efficient retrieval later on. | * For starters, the protocol makes extensive use of player identification numbers rather than names. This can be a nuisance when requiring the player's name for communication between, for example, different zones and databases. Try to effectively find one or multiple solutions to store the player id along with their name for quick and efficient retrieval later on. | ||
| − | * The colon (:) is used extensively in the TCP Protocol. Be wary of zone names, player names, passwords, and messages among others containing them. You will likely want to reject those zones and players from connecting, but there is no need from blocking extra colons in the final parameter. This includes | + | * The colon (:) is used extensively in the TCP Protocol. Be wary of zone names, player names, passwords, and messages among others containing them. You will likely want to reject those zones and players from connecting, but there is no need from blocking extra colons in the final parameter. This includes namely messages. If you intend on separating the parameters into an array of some sort, make sure to join the extra parameters together (do not forget to re-add a colon), otherwise player messages will be accidentally cut off (e.g. ''CHAT:0:2:0:<u>And then he said''':''' "what are you staring at?"</u>'' - The final parameter is the entire section underlined.). |
* Be careful about implementing "unlimited" of a certain feature. Although theoretically possible, biller hosts should still be allowed to control the limits, otherwise a mischievous player could attempt to exhaust the memory and space limits of the server and or database. | * Be careful about implementing "unlimited" of a certain feature. Although theoretically possible, biller hosts should still be allowed to control the limits, otherwise a mischievous player could attempt to exhaust the memory and space limits of the server and or database. | ||
| − | * When using and storing player passwords, make sure to hash them to prevent player names and passwords from being easily stolen should your database ever be compromised. The popular MD5 cryptographic function is no longer recommended, instead, you will want to look up the safety and reliability of [http://en.wikipedia.org/wiki/Cryptographic_hash_function#Cryptographic_hash_algorithms other hash algorithms] such as SHA-512, RIPEMD, or WHIRLPOOL for example. | + | * When using and storing player passwords, make sure to hash them to prevent player names and passwords from being easily stolen should your database ever be compromised. The popular MD5 cryptographic function is no longer recommended, instead, you will want to look up the safety and reliability of [http://en.wikipedia.org/wiki/Cryptographic_hash_function#Cryptographic_hash_algorithms other hash algorithms] such as SHA-512, RIPEMD, or WHIRLPOOL for example. Appending random salts to each password will greatly increase the odds that each password is unique, and it will ultimately make it more difficult and timely to crack (Do not use a straight-forward formula for generating the salt, e.g. ''password+username''. If this formula is known, then you have ultimately gained no more protection than the password alone). |
* ''CHA'''TT'''XT'' has a double t in it. | * ''CHA'''TT'''XT'' has a double t in it. | ||
Latest revision as of 18:04, 24 May 2010
Contents
What's so special about TCP billers?
TCP billers use a new simpler protocol compared to the original UDP billers. See TCP Billing Protocol for more details.
Can I use subgame with a TCP biller?
No, currently only ASSS can connect to a TCP biller. It is possible to use proxy to convert between the UDP and TCP protocols to allow subgame.
Why is there no ability for the billing server to shutdown/restart a server?
The ability of the billing servers to shutdown a zone server is a relic from the old system. The biller is no longer considered an administrative and control server, but simply a validation system used mainly to control bans and passwords for player names.
Are there any TCP billers available for public download?
Yes, but only unfinished ones.
- Two different versions of POCoB written by Smong are available at http://toktok.sscentral.com/ss-pocob.php.
- SkyBill written by Doc Flabby.
- UBill written by BDwinsAlt is available at http://forums.minegoboom.com/viewtopic.php?t=7543.
- Sius written by Hakaku is available at http://forums.minegoboom.com/viewtopic.php?t=8691.
Are there things I should be wary about when using the protocol?
Like any protocol, you will need to implement the TCP Billing Protocol with caution. The following applies mainly to those who plan on creating billers that implement it:
- For starters, the protocol makes extensive use of player identification numbers rather than names. This can be a nuisance when requiring the player's name for communication between, for example, different zones and databases. Try to effectively find one or multiple solutions to store the player id along with their name for quick and efficient retrieval later on.
- The colon (:) is used extensively in the TCP Protocol. Be wary of zone names, player names, passwords, and messages among others containing them. You will likely want to reject those zones and players from connecting, but there is no need from blocking extra colons in the final parameter. This includes namely messages. If you intend on separating the parameters into an array of some sort, make sure to join the extra parameters together (do not forget to re-add a colon), otherwise player messages will be accidentally cut off (e.g. CHAT:0:2:0:And then he said: "what are you staring at?" - The final parameter is the entire section underlined.).
- Be careful about implementing "unlimited" of a certain feature. Although theoretically possible, biller hosts should still be allowed to control the limits, otherwise a mischievous player could attempt to exhaust the memory and space limits of the server and or database.
- When using and storing player passwords, make sure to hash them to prevent player names and passwords from being easily stolen should your database ever be compromised. The popular MD5 cryptographic function is no longer recommended, instead, you will want to look up the safety and reliability of other hash algorithms such as SHA-512, RIPEMD, or WHIRLPOOL for example. Appending random salts to each password will greatly increase the odds that each password is unique, and it will ultimately make it more difficult and timely to crack (Do not use a straight-forward formula for generating the salt, e.g. password+username. If this formula is known, then you have ultimately gained no more protection than the password alone).
- CHATTXT has a double t in it.
- Always test the features you add and log the events and errors that occur. Even seemingly minor bugs could cause the biller disconnect a zone or crash.
