[DGD] API requirements for networking extensions

[Raymond Jennings]

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
>