[DGD] Network extensions, LPC interface

[bart at wotf.org]

Foreign ip:port and local ip:port as a combination make up this relationship.

As you mention, it is not really a connection, and indeed in case of reuse of
the same source port, 2 unrelated udp packets can be seen as part of the same
'connection'.

>From what I can tell, you should actually consider the connection object as an
object to handle a specific 'peer' for the purpose of buffering input on a per
peer basis, and not try to actually consider it a 'connection' in the sense of
datagrams arriving at the same connection object actually being related to
eachtother beyond coming from the same peer:port combination.

This has some interesting consequences for my work on a reimplementation of
the network extensions, see the preliminary notes at:

http://fortune.wotf.org/docs?codebase=dgd&browse=%2Fdoc%2Fnet%2Fnewnwe.txt

Bart.

On Wed, 29 Mar 2017 19:58:45 -0700, Raymond Jennings wrote
> Side question about udp "connections".
> 
> Since its all technically connectionless anyway, how exactly does
> vanilla DGD distinguish a "connection"?
> 
> Does it just classify a "datagram connection" as simply separating 
> the incoming packets based on their origin IP/ports?
> 
> On Wed, Mar 29, 2017 at 1:43 AM,  <bart at wotf.org> wrote:
> > It certainly also applies in other situations, but the more 'realtime' the
> > usage the more important it becomes to detect it quicklt.
> >
> > Bart
> >
> > On Wed, 29 Mar 2017 01:02:23 -0700, Raymond Jennings wrote
> >> On Wed, Mar 29, 2017 at 12:45 AM,  <bart at wotf.org> wrote:
> >> > On Tue, 28 Mar 2017 21:45:46 -0700, Raymond Jennings wrote
> >> >> Personally I've shied away from UDP in general.  It seems a bit
> >> >> hamstrung with red tape of a sort, especially considering
> >> >> datagram_challenge.
> >> >
> >> > datagram_challenge is part of the datagram channel for binary ports
interface,
> >> > but not of the generic udp port interface.
> >> >
> >> >>
> >> >> I'd also like to raise the issue for discussion of us presently
> >> >> living in an "internet of things" where mobile devices across the
> >> >> globe can be sending and receiving packets, and where internet
> >> >> connectivity is not always a sure thing.
> >> >>
> >> >> Just for the sake of discussion...I'd like to ask:  What do you do if
> >> >> you have a client that wants to interact with DGD, but doesn't have
> >> >> the luxury of maintaining a persistent TCP connection?  What do you
> >> >> do if that client loses connectivity and reappears with a new IP address?
> >> >
> >> > For my current 'web interface' code, I use a sessionid which does not
depend
> >> > on the client IP, and hence can be used to simply reconnect with the new IP
> >> > and continue where it left off. The server side can queue a limited
backlog of
> >> > output/events to cover the loss/re-establishment for situations where
this is
> >> > appropriate, or cause 'link-death' in cases where that would be more
> > appropriate.
> >> >
> >> > The biggest issue there is detecting the situation quickly so you don't
end up
> >> > with an in-game char which has no link for long enough to have an impact on
> >> > the game-play.
> >>
> >> I should probably also point out that the RPG/MUD/RP case is only one
> >> of many possible applications, and when I raised this issue I wasn't
> >> even thinking of RPGs specifically.
> >>
> >> An uber-like ridesharing application might also find importance here,
> >> for example.
> >>
> >> >
> >> > Bart.
> >> > --
> >> > http://www.flickr.com/photos/mrobjective/
> >> > http://www.om-d.org/
> >> >
> >> > ____________________________________________
> >> > https://mail.dworkin.nl/mailman/listinfo/dgd
> >> ____________________________________________
> >> https://mail.dworkin.nl/mailman/listinfo/dgd
> >
> >
> > --
> > http://www.flickr.com/photos/mrobjective/
> > http://www.om-d.org/
> >
> > ____________________________________________
> > https://mail.dworkin.nl/mailman/listinfo/dgd
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd


--
http://www.flickr.com/photos/mrobjective/
http://www.om-d.org/