[nanomsg] Re: nanomsg and udp
- From: Brian Knox <briank@xxxxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Thu, 22 Aug 2013 12:02:10 -0400
Games... fun! I've been working on a roguelike game in my spare time (what
little I have) just to write some code outside of my normal day to day. I
had some vague notions about turning it into a mud and using zeromq for it
- but I need an excuse to dive into the nanomsg api so I think I'll do that!
Brian
On Thu, Aug 22, 2013 at 10:43 AM, Zack Morris <zmorris@xxxxxxxxx> wrote:
> 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:
