JSON+UDP+DHT=Freedom

by nmcfarl • 14 years ago

174 39 14 years ago

nmcfarl2• 14 years ago

This wiki page got me much closer to understanding what's really going on here: https://github.com/quartzjer/TeleHash/wiki/My-Understanding-...

fleitz• 14 years ago

This would be a phenomenal way to build something like app.net.

With full decentralization it could really become a true 'protocol'.

ricardobeat• 14 years ago

or tent.io

gliese1337• 14 years ago

On Tent.io: http://news.ycombinator.com/item?id=4418904

spolu2• 14 years ago

This is absolutely Awesome, but the UDP part is kind of scary for any system that handles static data (not games, or stuff)

peterwwillis2• 14 years ago

You want some kind of enterprise messaging system or message queue, then, like Rendezvous, Spread, Talend, RabbitMQ, ActiveMQ, ZeroMQ, etc.

uncoder0• 14 years ago

There is nothing about App.net that is decentralized. Why do people think it is decentralized? It is a walled-garden with a better gate policy.

macspoofing• 14 years ago

>It is a walled-garden with a better gate policy.

...until they need money.

EwanToo• 14 years ago

With a more expensive gate policy, it might not be a better one :)

axx3• 14 years ago

EternalFury• 14 years ago

This is a nice mash-up. It would have been nice to preserve Kademlia's symmetrical distance metrics, though.

sudhirj• 14 years ago

I can just glimpse the promise this holds, but I don't really understand one would implement this. Does anyone have a blog post with example code?

If I've got a server that needs to receive messages, do I register it as an 'end'? And do I then send messages to this 'end' from other clients? How does it prevent two parties from registering the same 'end' hash?

medecau3• 14 years ago

end is a SHA1 of the ip+port of the endpoint so there won't be any collisions (hopefully)

buster• 14 years ago

There is some version 2.0 on its way: https://github.com/quartzjer/TeleHash/commit/14cecbb2e58dca4...

lucaspiller• 14 years ago

And if you don't like reading HTML:

http://telehash.org/v2.html

spolu2• 14 years ago

Why UDP? And Why create one implementation for each language?? Why not a local server?

b3tta• 14 years ago

To the "Why UDP?" part:

For things like P2P UDP is a much better fit, because TCP sends an ACK (ACKnowledgement) to the sender for every received packet.

Since UDP is unreliable no such ACKs will be send and it's up to the programmer to detect packet loss. The latency is therefore with UDP lower (and hence throughput higher), because the provider can push packets without waiting for a response.

For instance in P2P the receiver only needs to send a NAK (Negative AcKnowledgment) if and only if a packet/part is missing and then it will be resend by the provider.

icebraining• 14 years ago

TCP sends an ACK (ACKnowledgement) to the sender for every received packet.

Not quite. TCP receivers only need to send ACKs when they have received enough data to fill the sliding window. That may be every packet, every other packet (the recommended by the RFC) or more.

klibertp• 14 years ago

> to discover its public IP:PORT

What about switches that want to run from behind a NAT? Could it be that UDP was chosen with this in mind? (http://en.wikipedia.org/wiki/UDP_hole_punching)

alberich• 14 years ago

I was wondering how this approach deals with systems running behind NAT also. With IPv6 not happening anytime soon, there will be a large number of systems without individual public addresses available. Routing this UDP packets may require tweaking firewall rules, etc.

medecau3• 14 years ago

Switches behind NAT either have to configure a port to receive UDP directly or depend on some other switch for hole-punching.

arnoldb0620• 14 years ago

if server a is behind a nat, it first needs to send out a message to server b this will open a random port for typically 60 seconds automatically. Then another message will need to originate from server a within the 60 second time period in order to keep the port open.

http://en.wikipedia.org/wiki/NAT_traversal

towhans• 14 years ago

I am a programmer yet still I don't get what this is. If an app wants to send JSON to another app why not use HTTP for that. DNS will take care of the routing. The only thing that seems novel to me is their use of UDP which is faster then HTTP.

artumi-richard• 14 years ago

Is it to bypass DNS? With all the moves to control the internet around, then an encrypted peer-to-peer decentralised system that can deal with any kind of data would allow for DNS-less email / websites etc etc...

Though the main point of DNS is it manages a namespace, and you wouldn't want clashes, so websites would probably have to have urls like thttp://{some 64char hash}/

(Where the h stands for telehash...

arethuza3• 14 years ago

Here is the bit I don't get - how do you do a lookup to get that hash?

i.e. Map from something user friendly (e.g. username) to a SHA1 hash?

medecau3• 14 years ago

The use of UDP allows for "hole-punching".

User A wants to send and receive messages with user B. Both are identified only by their IP and Port pair. User B does not know of user As intentions. So user A send switch C an UDP packet asking for "hole-punching". Switch C has this service where users behind NAT routers connect and signup to be contacted when someone wants to "hole-punch" to them. Switch C sends a packet to B with info about A. B sends A a packet and Bs router is now expecting packets from A. Has soon has A sends its first packet to B its router is open for packets from B. Now both A and B can send packets to each other without C.

DNS is not yet entirely out of the loop. The main switch for telehash is telehash.org:42424

hdradionet• 14 years ago

UDP+DHT+NAT Traversal is very powerful. I implemented a new p2p radio platform called HD Radio.NET (http://hdradionet.zapto.org/) which is completely based on them. It shows to be very effective. In this news, Jason is a new idea, it may bring some benefits, for example, running something in browser.

jsilence• 14 years ago

Reminds me of peercast. Which seems to be quite dead, unfortunately.

In you FAQ it says it is cross platform, but there is only Windows software on the download page.

popee• 14 years ago

You could have problems with NAT, but SIP protocol has STUN and ICE which are responsible for dealing with this. Check that out.

Btw i had idea SIP + JSON/HTML + DHT which would not suffer with "man in the middle attack" that HTTP has as designed decision. You could connect, for example, with HTTP/FTP/... protocols to your buddies directly. You just have to make right SDP packet when calling them ...

keithwinstein• 14 years ago

This is very interesting. We looked at storing stuff in BitTorrent's Kademlia DHT to do roaming NAT-traversal in Mosh, but their performance scared us off. Before building an application on this I would want to ask:

- Who runs telehash.org? Will they still be around in five years? Is there a well-known list of anchor nodes I can hardcode into my app, or how does the program find the DHT when it first starts?

- What is the median time to retrieve a key? What will it be in 24 months?

- What is the percentage of failed requests? Can we guess what that will be in 24 months?

The "mainline" BitTorrent Kademlia DHT started off great but now the statistics are apparently abysmal. In one academic study, the median time to retrieve a key was over a minute, and 20% of retrievals failed. (See http://www.cs.rice.edu/~scrosby/tr/BTMeasure-Main.pdf)

Why won't the same fate befall this Kademlia DHT?

(Edit: is this _A_ DHT, or is the idea that if you build your program to use Telehash, you are creating your own DHT that is only used by currently-running instances of the same program?)

nmcfarl2• 14 years ago

> (Edit: is this _A_ DHT, or is the idea that if you build your program to use Telehash, you are creating your own DHT that is only used by currently-running instances of the same program?)

I had assumed the later, but the existence of telecast.org:42424 kind of points against it. It's possible that we've got both going on.

JSON+UDP+DHT=Freedom

Related Stories