@notjack I’m working on connectors. Just noticed a potential issue with the net2/connector module API as documented.

racket@connector.rkt&gt; (define c (tcp-connector)) racket@connector.rkt&gt; c (connector #&lt;procedure:connect-proc&gt; #&lt;custodian&gt;) racket@connector.rkt&gt; (define t (connect! c (string-&gt;authority "<http://www.google.com:80\|www.google.com:80>"))) racket@connector.rkt&gt; t (transport #&lt;input-port:www.google.com&gt; #&lt;output-port:www.google.com&gt; (authority (ip6 #"&amp;\0lPa\177\315\373\36oe\377\376\237H/") 59472) (authority (ip6 #"&amp;\a\370\260@\2\b\a\0\0\0\0\0\0 \4") 80))

I saw the input-port name was <http://www.google.com\|www.google.com>.

Right now, we have no generic way to get the original domain name back. Do you think we should be storing that info with the connector?

This is not blocking anything currently, and I don

’t see it being a problem in the near future.

I think the Right way to handle that would be reverse DNS lookup of the transport destination authority

I’m fine with that.

Should it be a net2 operation, or user defined?

ip->dns?

Eventually I’d like DNS queries and lookups to be a thing mostly done in Racket instead of relying on the host machine’s implementation, but I haven’t planned that far ahead

Also, I think the connectors implementation is blocked on a bunch of disposable implementation changes and feature additions

Getting familiar with that code and reading the issues might be a good next step in your axon integration efforts

I’ve been reading the disposable code. The axon/net2 experiment is my disposables playground.

I’m also making axon/tcp compliant with net2 APIs as I go, mainly to get an end-to-end feel for the design. Drop-in replacement of real net2 is a bonus.