[DGD] API requirements for networking extensions

[bart at wotf.org]

Obviously, below only works for the network extensions (current version), and
not for vanilla DGD. I'm not aware of a way to obtain this information from
LPC without using the network extensions.

Bart

On Tue, 18 Apr 2017 17:10:28 +0200, bart wrote
> And I answered exactly that question.
> 
> The *REMOTE* port is passed to the connect() call. This is possible because
> the local port is already known.
> 
> Keep in mind you have a unique port object for each port. This port object
> must know its own listen port, and hence also the local port for any 
> inbound connections handled by the port object, so:
> 
> You have the local port from the port object directly, and you get 
> the remote port as argument to connect()
> 
> Bart
> 
> On Tue, 18 Apr 2017 07:22:44 -0700, Raymond Jennings wrote
> > I said remote port.
> > 
> > Especially for connections arriving on the vanilla ports sent to the 
> > driver object.
> > 
> > On Tue, Apr 18, 2017 at 6:26 AM, <bart at wotf.org> wrote:
> > 
> > > When looking at the current implementation, it is passed to connect().
> > > This is possible because connect() gets called in a port object, and this
> > > port
> > > object already knows its local port.
> > >
> > > Bart
> > >
> > > On Tue, 18 Apr 2017 04:32:57 -0700, Raymond Jennings wrote
> > > > And at what point, if any, would information about the remote port number
> > > > be available?
> > > >
> > > > This information can be useful for auditing or enforcing security
> > > policies
> > > >
> > > > (sitebanning a griefer behind NAT, for example), and quite frankly
> > > > IMO should be made part of the baseline version of dgd somehow.
> > > > Maybe something like query_ip_port()
> > > >
> > > > Also, will it eventually be able to send UDP packets arbitrarily,
> > > >  much like how connect() can be used to open arbitrary outbound
> > > > connections?  Maybe the "connect" call can be used to set up a udp
> > > > connection of the same kind returned by datagram_connect
> > > >
> > > > On Tue, Apr 18, 2017 at 3:28 AM, <bart at wotf.org> wrote:
> > > >
> > > > > From my point of view:
> > > > >
> > > > > open_port() from the current network extensions should be extended to
> > > > > support
> > > > > listening on specific addresses (ipv4 and ipv6). Additionally it
> > > should be
> > > > > changes to use the listen/accept functionality from 'base' instead of
> > > > > adding
> > > > > its own (it may need some wrapper functions for this).
> > > > >
> > > > > UDP, use current 'base' implementation instead of the one from the
> > > network
> > > > > extensions.
> > > > >
> > > > > Outbound TCP: use 'base' implementation instead of the one from the
> > > network
> > > > > extensions.
> > > > >
> > > > > Functionally, that covers everything except for initiating outbound UDP
> > > > > traffic, and should share as much code as possible with the 'base' DGD
> > > > > implementation.
> > > > >
> > > > > I think it is important to extend open_port() such that it remains
> > > backward
> > > > > compatible with the current version, this could be done by making its
> > > port
> > > > > argument 'MIXED' and it accept either a string like "address:port" or
> > > an
> > > > > int
> > > > > (just the port number). It should also support "*:port"
> > > > >
> > > > > This will break backward compatibility for outbound connections
> > > (minor, the
> > > > > optional protocol argument won't be available anymore, and errors will
> > > > > cause a
> > > > > call to unconnected() instead of receive_error(). The proper code for
> > > this
> > > > > should already be in most LPC codebases for DGD). It will also break
> > > UDP
> > > > > connectivity but I don't see how the current network extensions udp
> > > > > implementation can be revamped to use the new 'base' UDP
> > > implementation.
> > > > >
> > > > > A note about open_port(), currently it can be used to open a random
> > > high
> > > > > port,
> > > > > this functionality is required for supporting protocols like passive
> > > FTP
> > > > > (example, there are more, and the argument of ftp being outdated does
> > > not
> > > > > apply).
> > > > >
> > > > > As open_port() is more or less critical for being ale to migrate to a
> > > new
> > > > > version, I believe it should be backward compatible from the LPC point
> > > of
> > > > > view. I don't think this is as important for outbound connectivity and
> > > UDP.
> > > > >
> > > > > Beyond that, things will change anyway, good moment for cleaning
> > > things up
> > > > > where possible.
> > > > >
> > > > > Bart.
> > > > >
> > > > > On Tue, 18 Apr 2017 10:48:53 +0200, Felix A. Croes wrote
> > > > > > Raymond Jennings <shentino at gmail.com> wrote:
> > > > > >
> > > > > > > What requirements, if any, would their be for a new version of the
> > > > > > > networking extensions?
> > > > > >
> > > > > > The main requirment is that it shares more code with the vanilla
> > > version.
> > > > > >
> > > > > > For example: the network extensions's "connect" function could not be
> > > > > > executed from within atomic code; the vanilla version could.  Another
> > > > > > example: the network extensions had no IPv6 support.
> > > > > >
> > > > > > Regards,
> > > > > > Felix Croes
> > > > > > ____________________________________________
> > > > > > 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/
> > >
> > > ____________________________________________
> > > 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


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