Currently unreleased client updates:
1) Client can now specify what port number it wants the bridge to connect to, using standard hostname with port string syntax. For those who may not know what this means:

portion before the : is the hostname
portion after is the port number

If you do not specify a port number, the default is used (51701). The default port can be changed in the bridge config.

2) For server broadcast messages, the log line on the calculator shows up with a globe icon to indicate server message. Thanks to beckadamtheinventor for creating that particular sprite.

Currently live server updates:
1) For registration, email verification (via a regex) is added... invalid emails trigger registration failure.
2) An automated karma system for users is implemented as a form of bad-practice barring from the service. It works as such:
- User joins, initial karma is set to 10.
- Every packet the server receives from that user increments the karma by 1 (capped at 100)
- Every packet that fails one of two checks causes your karma to decrease by 2:
--- Attempting to send packet types you should only be able to send while logged in when not logged in
--- Sending a text field with special characters)
- A user (or IP) that hits 0 karma receives an IP ban.

What is the simplest, most portable way, in Python, to detect if a service you are attempting to connect to is using SSL or not?
I'd sidestep the issue by one of the following solutions:
* using a protocol which starts as plain binary, and quickly negotiates features before switching to (D)TLS mode if the client supports (D)TLS. That's a STARTTLS approach, used by e.g. FTPS and SMTPS. This mostly protects privacy, but leaves the door open to interference: a MITM attack could make the server believe that a client does not support (D)TLS;
* better: simply deprecating plain binary communication and mandating (D)TLS support Smile
If you want to provide an upgrade path, you could provide two different services on two separate TCP / UDP ports for plain binary connections and (D)TLS-only connections - just like HTTP and HTTPS. This leaves the old protocol subject to the same privacy and integrity issues as before, and clients which support only it will eventually disappear when upgraded for functionality or security reasons.
Hmm. Well this is for TI-Trek.
The custom service can run with or without an SSL context, and I'm trying to have the clients (and by extension the bridge) have a "prefer SSL" config option whereby the bridge tries an SSL connection, and if that fails, falls back to normal.

I suppose the easiest method is to reserve 2 ports for the service, one set by default as the SSL-wrapped context and another as the non-SSL.
The SSL context could run on `port` and the non-SSL on `port+1`.
The service first tries an SSL connection to `port`. If no active service is detected it attempts a non-SSL connection to `port+1`. It would just have to be documented that the service requires 2 sequential ports available, but will only use one of them.

We have only a few more things to implement before the combat beta is ready for testing:
1) Chunk-wise server loading
2) Entity movement
3) Collision
4) Physics related to the above 3
5) Wrapping up lose ends that need to implemented to ensure all legs of the project handle the above fully and properly.

While progress on server-side stuff has slowed, I have been hard at work on documentation and on improving the user interface.
Firstly, the default ship configuration modules have been settled upon (some stats have yet to be added). All players will start with the following systems:
(1) Life Support, (2) Energy Core, (3) Orbital Thrusters, (4) Sublight Engines, (5) Phaser Type Weapon

Secondly, I have added some additional hostname configuration options:
Prepend the entire hostname string with s: to enabled SSL for this specific entry.
Append a custom port number to the hostname :PORT to specify a non-standard port.
Default port is 51701.
The default option for SSL is specified in the Settings menu. If you set Prefer SSL to true, the bridge will always attempt an SSL connection first, falling back to non-SSL if it fails. If Prefer SSL is false, SSL will only be used if the prefix is used. See below.

play.titrek.us   ==> non-SSL, default port (51701)
play:titrek.us:PORT   ===> non-SSL, port specified (PORT)
s:play.titrek.us   ===> SSL enabled, default port (51701)
s:play.titrek.us:PORT   ===> SSL enabled, port specified (PORT)

And last but not least, the WIP documentation for the game: http://titrek.us/components/downloads/usersguide.php
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
» Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8, 9, 10
» View previous topic :: View next topic  
Page 10 of 10
» All times are GMT - 5 Hours
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum