[DGD] API requirements for networking extensions

[Dread Quixadhal]

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