Skylive Protocol

The actual protocol is something crappy and definively insicure.

We are working on a complete new protocol, which will be XML based, and more extendible and more standardized than the actual one.

Also, the new protocol will be encapsulated in different transports to permit things like firewall/proxy bypass, and/or maybe also p2p distribution in future.

Initially we will work with an HTTP Tunnel transport only, but sometime in future we will add also other transports too, like DNS Tunnel and so on.

So, when skyliveNG will reach milestone 0.2, it will have a completely new protocol. But what about old clients? And what about few people using Skypromega old client?

Yes, ther's still some few peoples that actually are using the old skypromega client, cause they are inside a LAN secured by a proxy that don't permit the CONNECT method except for the tcp port 443. Actually we redirect this port on the server to the skyliveng port 10443, and we have a retro-compatible protocol running. This is, of course, a temporary solution, i won't to have the port 443 used for a non https protocol.

So, we need a migration path that let's our users pass gradually to the new protocol before to drop the old one completely. And also we need to develop the new protocol in successive steps.

This would let our staff vulnerable to another problem: how to manage many "whole clients upgrade" without any disage for our users?

This is the migration path to fix all those issues:

STEP .1 -> autoupgradable client with proxy support

We will first release a client that can be auto-upgradable. This way when an upgrade is required, the user only need to click "OK" on a popup window. This client will use the old protocol with a little extension to manage upgrades, but it will encapsulated in a Transport Layer HTTPTunnel. This will let's proxyfied users to switch to SkyliveNG.

STEP .2 -> drop 443 port redirect

When all users will be switched to the new autoupgradable client, we will drop the 443 port redirect.

STEP .3 -> new client with new protocol

At this point we can do gradual client upgrade to the new protocol.

STEP .4 -> drop old protocol

When all clients are on the new one, no more needs for the old one.

STEP .5 -> move live and fits images to the new protocol

Actually all live images and fits are simply downloaded from a web server extarnal from the skyliveserver itself. Now we can move all those downloads inside our protocol and drop external downloads.

STEP .6 -> protocol/transport extending

Now we are on our new protocol, we have a client auto-upgradable and we can do what we need. The new protocol will be extensible and we will try to let it be retro compatible in any new revision. Also, it will be completely standardized and public under a free license, so, anyone that want to implement a new client or connect an already existant software, can do that.

STEP .7 (maybe) -> release a library that implement the protocol

Maybe at this point will be a good idea to release a library to be used by anyone that want to interface with skylive to support our protocol.

---

New Protocol Sparse things

• It will encapsulate in some way also INDI protocol to let the client do telescope sharing
• It need to be encapsulabile in every transport we want
• It need to be SECURE (maybe delegated to the transport layer?)
• The password will NEVER pass on the protocol in clear text nor in encrypted/hashed way.
• it is better that the client don't need to know the password in clear text at all, just an hash would be enough.