Tracker Protocol

[al...@alexchamberlain.co.uk]

Hi,

I was reading through the protocol tonight to try to understand how clearskies works. Couple of questions about the Tracker.

`core.md` states that "The tracker is a socket service. The main tracker service runs at clearskies.tuxng.com on port 49200. Only one connection to the tracker is necessary." I understand it is currently a HTTP server, but will the new protocol use TCP or UDP (or either)?

It also says that clients should ping periodically. How does the client know the tracker is still there? Have you considered having a disconnect message (in either direction)?

This all happens over an unsecure connection. Even if this doesn't expose the contents of shares, it does expose open servers to everyone, instead of just those with a given ID? This assumes that a given "tracker.peers" message is only sent to each of the peers listed?

Hope that is all clear? Looking forward to a good, distributed, open source solution to file sharing.

Thanks,

Alex

[Steven Jewel]

On 03/11/2014 03:53 PM, al...@alexchamberlain.co.uk wrote:
> `core.md` states that "The tracker is a socket service. The main
> tracker service runs at clearskies.tuxng.com on port 49200. Only one
> connection to the tracker is necessary." I understand it is currently
> a HTTP server, but will the new protocol use TCP or UDP (or either)?

Yes, we removed the old tracker protocol, which was over HTTP, for a
single, long-lived TCP connection. I will fix this in the spec.

> It also says that clients should ping periodically. How does the
> client know the tracker is still there? Have you considered having a
> disconnect message (in either direction)?

If the tracker goes away, the ping messages won't be able to send. I
think that a disconnect message won't be necessary, since either party
can simply close the socket.

I think we'll want to tune this to get the best battery life on mobile
devices, so I've been waiting until we have a new tracker (and a working
android implementation) to be able to experiment.

> This all happens over an unsecure connection.

This is mostly a problem on open wifi networks, and it would expose that
you're running clearskies. We can fix this by having it be an SSL
connection, signed by a public CA.

> Even if this doesn't
> expose the contents of shares, it does expose open servers to
> everyone, instead of just those with a given ID? This assumes that a
> given "tracker.peers" message is only sent to each of the peers
> listed?

The tracker will only give the peer list to those with the same ID. I
will see if I can word this part of the spec better.

>
> Hope that is all clear? Looking forward to a good, distributed, open
> source solution to file sharing.

Thanks for reading through the spec and I appreciate the questions!

Steven

[Alex Chamberlain]

Thanks for clearing that up; I might mock up a small tracker server.
Couple of comments below...

On 11 March 2014 22:13, Steven Jewel <clear...@stevenjewel.com> wrote:
> On 03/11/2014 03:53 PM, al...@alexchamberlain.co.uk wrote:
>>
>> `core.md` states that "The tracker is a socket service. The main
>> tracker service runs at clearskies.tuxng.com on port 49200. Only one
>> connection to the tracker is necessary." I understand it is currently
>> a HTTP server, but will the new protocol use TCP or UDP (or either)?
>
>
> Yes, we removed the old tracker protocol, which was over HTTP, for a single,
> long-lived TCP connection. I will fix this in the spec.
>
>
>> It also says that clients should ping periodically. How does the
>> client know the tracker is still there? Have you considered having a
>> disconnect message (in either direction)?
>
>
> If the tracker goes away, the ping messages won't be able to send. I think
> that a disconnect message won't be necessary, since either party can simply
> close the socket.
>
> I think we'll want to tune this to get the best battery life on mobile
> devices, so I've been waiting until we have a new tracker (and a working
> android implementation) to be able to experiment.
>

Is there a battery cost to maintaining a TCP connection? ie is UDP
cheaper in this regard? It is my understanding - correct me if I'm
wrong - that UDP is stateless and thus you wouldn't be able to rely on
closing the socket to disconnect/unregister.

>
>> This all happens over an unsecure connection.
>
>
> This is mostly a problem on open wifi networks, and it would expose that
> you're running clearskies. We can fix this by having it be an SSL
> connection, signed by a public CA.
>

It's a shame to introduce an external dependency on a CA just for the
tracker service. I wonder if a public certificate can be distributed
with clients instead (given they already need a URL)?

>
>> Even if this doesn't
>> expose the contents of shares, it does expose open servers to
>> everyone, instead of just those with a given ID? This assumes that a
>> given "tracker.peers" message is only sent to each of the peers
>> listed?
>
>
> The tracker will only give the peer list to those with the same ID. I will
> see if I can word this part of the spec better.
>
>
>>
>> Hope that is all clear? Looking forward to a good, distributed, open
>> source solution to file sharing.
>
>
> Thanks for reading through the spec and I appreciate the questions!
>
> Steven
>

> --
> You received this message because you are subscribed to the Google Groups
> "ClearSkies Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clearskies-de...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Steven Jewel]

On 03/11/2014 04:25 PM, Alex Chamberlain wrote:
> Is there a battery cost to maintaining a TCP connection? ie is UDP
> cheaper in this regard? It is my understanding - correct me if I'm
> wrong - that UDP is stateless and thus you wouldn't be able to rely on
> closing the socket to disconnect/unregister.

This is where I need to experiment and do more research. A UDP
connection would need frequent keepalives to not have its entry removed
from the carrier's NAT table, but maybe that's true for TCP too.

We might be able to mimic what Google and Apple is doing for its push
notification service, since they will be facing similar problems.

You're right about a deregister event for UDP. If we go that route we'd
want that, in addition to having the ping messages going in both directions.

> It's a shame to introduce an external dependency on a CA just for the
> tracker service. I wonder if a public certificate can be distributed
> with clients instead (given they already need a URL)?

That would be fine by me.

Steven