[DGD] API requirements for networking extensions

[bart at wotf.org]

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/