[nanomsg] Re: nanomsg and udp
- From: Zack Morris <zmorris@xxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Thu, 22 Aug 2013 08:43:51 -0600
On Aug 22, 2013, at 12:28 AM, Martin Sustrik wrote:
> Hi Zack,
>
>> Hmm DCCP looks pretty cool but how supported is it? Games and p2p
>> just use UDP and TCP right now.
>
> It's in linux kernel, but the firewalls and NATs virtually prevent it to be
> used on WAN.
>
>> Originally I think a mistake was
>> made in the design of the internet where it should have gone
>> IP->UDP->TCP instead of IP->UDP and IP->TCP. That way if TCP worked,
>> UDP would have too, and we wouldn't have run into the problems with
>> NAT we have now for UDP. Although NAT issues are by design in many
>> ways, so perhaps we still would have. I realize that TCP header
>> savings used to be important but I don't think they are nearly as
>> much now except for wireless.
>
> I think you underestimate human ability to screw things :)
>
> Interesting related paper btw:
> http://tools.ietf.org/html/draft-tschofenig-hourglass-00
>
>> Mainly what I would like is a wrapper that turns an unreliable layer
>> like UDP into a reliable one. Like literally give me a socket that
>> acts like a TCP socket but uses UDP internally. I thought about
>> implementing this somehow as a library that returns a pipe to the
>> process but didn't get far with it. I'm still reading about nanomsg
>> and it looks like it doesn't maintain its own queues, so I'm
>> wondering if it's even possible.
>
> If you want it to behave like TCP, why not simply use TCP? What are the TCP
> shortcomings you are trying to overcome?
>
> Martin
Thanks for the info and link (that was almost a, funny? RFC hah). I heard
somewhere that even IPv6 has a notion of NAT, so it will likely still cause
headaches. I've never understood why companies work so hard to limit
communication. My theory is that network administrators are quite intelligent
but that trying to map corporate needs onto the general public for broadband
has been an emperor-has-no-clothes failure. I can't even imagine what tech
support must cost telecoms! But I digress.
Anyway, I've worked on a few shareware games and tried to add networking and
it's always been a disaster. NAT stinks, since it made most users second class
citizens who can't accept incoming TCP connections. So the choice is either to
try to get universal plug and pray working or go around the problem with STUN
and UDP (which incidentally still has a chance of failure, just smaller).
There are no off the shelf libs for p2p networking but this one came pretty
close conceptually before it defuncted:
http://web.archive.org/web/20020413011011/http://gatorhole.com/gamecom/index.html
http://web.archive.org/web/20020602074526/http://gatorhole.com/gamecom/gcdocs.html
I adapted several of the concepts from gamecom in my own TCP-like layer over
UDP. It took two years and a few tens of thousands of dollars on my credit
cards and I ended up failing anyway because networking is very, very hard to
get right. I had something that worked 99% of the time but the edge cases were
killing me and I just couldn't trust it. It hobbled my ability to write the
layer above that for sharing state (I didn't learn about things like RPC or
software transactional memories/STM until later, although my lib did a good job
with atomic operations). For what it's worth, Google's Go solved many of the
problems I was encountering, because it has a lot of concepts from Erlang but
who knows Erlang?
If I attempt it again, I'll probably use ZeroMQ or something like it. I think
what the world really needs is a middle layer that can take one or more
unreliable packet protocols and provide a pipe or stream over it. I want to be
able to refer to peers with a 64 or 128 bit token or hash and always be able to
reach them even if they change networks. I'm excited about webp2p but haven't
used it yet, and don't know how good the libs are outside web browsers. In an
ideal world, here are the layers I want (I think of this as the real Web 2.0):
P2P (TCP with optional OOB/urgent/unreliable messages over UDP, SMS, carrier
pigeon)
TLS/SSL (certs either from an authority, or a web of trust like PGP)
DHT (distributed hash table that uses hash instead of IP address to retrieve
data like BitTorrent)
DSTM (distributed software transactional memory that can handle unreliable
messages for realtime gaming)
So to join a network game, you would find its identifier address somewhere,
request to get added as a peer with your credentials, and it would give you a
list of hashes to begin downloading levels or whatever from the cloud over the
DHT. Then there would be a standardized STM that "just works" so if two people
take out an enemy at the same time, it decides who gets the point, or if you
open a door, it decides which data to flood you with, based on some rule
system. You would edit the rule system in a standardized way, maybe prolog or
in a functional way like Excel, so you aren't running down blind alleys that
require refactoring beyond your ability.
In terms of difficulty, they probably go DSTM->P2P->TLS/SSL->DHT in descending
order. I can live without the DSTM though and just use RPC with one of the
peers acting as a central server for now. I was going to fake security by just
grabbing a cert from an authority and encrypting the P2P stream myself before I
passed it to the pipe. Anonymity, privacy and cheating are hard to get right
but by that point I'd supposedly be making enough money from the game that I
could refactor.
Ya so that's the goal, hope this wasn't too much of an overshare but maybe it
sheds some light on what I'm asking for! I would love to know if there's a
generalized windowing library out there with an MIT or LGPL license because it
would make the UDP->TCP layer a lot easier to write. Also a huge plus would be
how to open a stream/pipe/socket between the lib and parent process in a cross
platform way, because I want all the normal file descriptor operations to work
on it (missing that's not a deal breaker though).
Zack Morris
Other related posts:
