Re:TeleHash: Distributed JSON Peering Protocol
by grayrest on Thursday May 20, 2010 @12:31AM
(#1363255)
Care to expound on that?
[ Parent
| on HN ]
Re:TeleHash: Distributed JSON Peering Protocol
by tlack on Thursday May 20, 2010 @01:22AM
(#1363311)
The idea of using JSON in a very informal, global messaging system is a really strong one. Messaging is huge these days but pub/sub systems still aren't as commoditized as they should be.
However, Telehash's reliance on UDP means we'll still be worrying about whether or not our message made it. Its' confusing lexicon (telex? dial? listen?) is unnecessary for simple cases.
Telehash should be simpler and closer to HTTP.
tldr: we spend too much time writing pub/sub systems that talk JSON, but this is too much to learn.
I think the choice of UDP is based on the use of Kademlia:
Re:TeleHash: Distributed JSON Peering Protocol
by catch23 on Thursday May 20, 2010 @01:51AM
(#1363340)
maybe they used udp for speed and for udp hole punching over firewalls.
Re:TeleHash: Distributed JSON Peering Protocol
by adulau on Thursday May 20, 2010 @01:59AM
(#1363354)
If you want to use the protocol within a browser, there is no standard (included by default in the browser) UDP socket interface accessible from js. Nice to use JSON but I'm still wondering how they could use UDP from the Browser? using "faked" DNS queries to generate UDP traffic?
Re:TeleHash: Distributed JSON Peering Protocol
by tlack on Thursday May 20, 2010 @02:18AM
(#1363372)
There's a reason most of the world uses TCP.. even for things that sound ideal for UDP.
Re:TeleHash: Distributed JSON Peering Protocol
by agentultra on Thursday May 20, 2010 @08:32AM
(#1363845)
When you've got a hammer...
TCP isn't ideal for everything. Ad-hoc networking and broadcast streaming being just two.
There's a reason why UDP was invented.
Re:TeleHash: Distributed JSON Peering Protocol
by jrockway on Thursday May 20, 2010 @10:50AM
(#1364152)
There's a reason why UDP was invented.
And that reason was not sending time-insensitive text messages.
JXTA handles this by specifying neither. Instead they have a "pipe" abstraction. Once peers discover each other they can open a pipe that may, depending upon the network conditions, be a fast TCP implementation (when a direct connection is possible) or a slower, but usable pipe built on HTTP with polling (for being able to traverse firewalls).