[DGD] API requirements for networking extensions

[bart at wotf.org]

The connection object does not get all that information, this discussion
concerns a way for LPC code to get more of this information, specifically the
remote port. The remote IP is already known using the (rather common)
query_ip_number( object ) kfun, and the local port is available to LPC as
well. Whatever interface connection objects offer is upto whatever lib you use
or build.

So this is about the interface between dgd and lpc, and about replacing the
old network extensions with a new implementation.

See also:
http://fortune.wotf.org/docs/?codebase=all&browse=%2Fdgd%2Fdoc%2Fnet%2Fnewnwe.txt&search=network%20reimplementation

Also read the mailinglist discussions concerning DGD 1.6 and your log from the
dgd channel.

Bart.

On Tue, 18 Apr 2017 13:12:05 -0400, Dread Quixadhal wrote
> Why not just have the object itself return that information?
> 
> Such as conn->connection_details() returning a mapping with the 
> information it has about itself.
> 
> ([
>     “local host” : “foo.com”,
>     “local IPv4” : “123.123.123.1”,
>     “local port” : 1234,
>     “local IPv6” : nil,
>     “remote host” : nil,
>     “remote IPv4” : “234.234.234.1”,
>     “remote port” : 23456,
>     “remote IPv6” : nil,
> ])
> 
> Or something like that?  I assume the connection object gets all 
> that information as it is being established? You could obviously 
> break each part out as a separate method, if you wanted to get one 
> detail without a whole mapping, but the caller could do that too.
> 
> Sent from Mail for Windows 10
> 
> From: Raymond Jennings
> Sent: Tuesday, April 18, 2017 12:23
> To: All about DGD and Hydra
> Subject: Re: [DGD] API requirements for networking extensions
> 
> Actually I think I made a bit of a booboo here.
> 
> I might have gotten your reference to the connect() system call in 
> the OS confused with the connect() kfun provided by DGD to the lpc layer.
> 
> *wears dunce cap*
> 
> I still stand by what I said though about query_ip_port() being a clean
> idea that I personally think has merit even in the baseline code.
> 
> On Tue, Apr 18, 2017 at 9:03 AM, Raymond Jennings 
> <shentino at gmail.com> wrote:
> 
> > Just to be clear, I was talking about getting the remote port from *any*
> > connection, both ones created via connect() and ones received locally,
> > either by the driver from a port opened by configuration, or by a port
> > object that was opened.
> >
> > Basically, given the need for code unification, the solution I was hoping
> > for would be one that would be able to treat all connections the same way
> > no matter how they were established (whether outbound via connect(), or
> > inbound via the driver object or a port object).
> >
> > I think a query_ip_port(object conn) kfun would be a neat and tidy way to
> > get this information.
> >
> > To a lesser extent I also think that this information would be useful even
> > in vanilla dgd for the same reasons even if the network extensions were NOT
> > enabled.
> >
> > Felix, bart, what do you think?
> >
> >
> ____________________________________________
> 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/