[DGD] API requirements for networking extensions

[Raymond Jennings]

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