[DGD] API requirements for networking extensions

[bart at wotf.org]

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/