[nanomsg] Re: NAT transport
- From: Jay Berg <jaybny@xxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Wed, 25 Mar 2015 19:22:45 -0700
RTP sounds like a plan...
regarding BitTorrent, more and more communications are happening via p2p
protocols, and with Bitcoin and now all the new Distributed Applications
(DAPPS), its just going to increase. and now that we are out of ipv4
addresses and still waiting on ipv6, we will be dealing with NAT issues for
the foreseeable future.
I believe BitTorrent uses some kind of TCP hole-punching using a third
party and if that fails, you can only leech. I'm curious how Bitcoin does
it. can it be that all those people running "full-nodes" to help "support
the network" are not really doing anything at all?
Another project to look at is Bitshares and Ethereum ..
My dapp (Satoshi Fantasy) is geared towards less technical users, so it
needs to deal with NAT to NAT without forcing users to configure router or
firewall.
On Wed, Mar 25, 2015 at 6:57 PM, Matthew Hall <mhall@xxxxxxxxxxxxxxx> wrote:
> On Wed, Mar 25, 2015 at 06:39:05PM -0700, Jay Berg wrote:
> > for some applications this really is not a big deal.. high frequency
> > trading price feeds are all UDP. using check-sums and higher level
> > protocols such as FIX can resolve any missed data.
> >
> > as long as both sides are running the same protocol with defined
> timeouts,
> > reply/requests and handshakes, UDP communication is just fine. isn't
> > 猥orrent all UDP?
>
> Sure, there are plenty of options if you want to toss out the guarantees.
> We'd
> need a new transport that had spray-and-pray, or auto-retransmit
> semantics, as
> desired, along with a 64KB message size limit, so it can fit the messages
> into
> single datagrams (which the IP stack would fragment).
>
> BitTorrent uses TCP for the tracker, and TCP for the data normally.
>
> https://wiki.wireshark.org/BitTorrent
>
> They also validate the chunks of data by dividing files in pieces and
> calculating SHA1 sums on the pieces.
>
> The most classic UDP-heavy real-time low-latency protocol with PMTUD,
> segmentation, loss detection (not loss correction), reordering /
> de-jitter, is
> definitely RTP (Real-Time Protocol), for streaming audio and video, hence
> we
> should see how the RTP stacks work if we want to get a good solution for
> nanomsg. They handle a lot of the hairy issues so we could concentrate
> more on
> the messaging layer than raw transport headaches.
>
> Matthew.
>
>
--
PGP: http://bit.ly/1gjvndi
Other related posts:
