RejectedSoftware Forums

Hmm ok, one more question on this... is there any way to basically do a "connectTCP" using a NetworkAddress instead of the host/port combo? I need to be able to connect to a system who's address I have only from a UDP packet (i.e. NetworkAddress structure) and there doesn't seem to be a way to convert that back to a string that I can see.

It looks like the driver implementations of connectTCP all immediately construct a NetworkAddress using resolveHost from the incoming parameters, so perhaps it wouldn't be too tough to provide this variant? Maybe have the drivers just use NetworkAddress structures directly and turn the current version of connectTCP into a little stub that calls resolveHost, etc?

Am 24.01.2014 20:15, schrieb punkUser:

Ugh, and no sooner do I post this than do I notice the "peer_address" optional parameter on recv... no idea how I missed that when looking around yesterday :S

Still curious about constructing a network address with port, but pretty low priority, thanks :)

It's currently a bit sub optimal, because parsing IP addresses requires
OS specific functions and is thus done in the event driver. But
eventually, I'd like to have this functionality available directly in
NetworkAddress, either by writing an own IP address parser, or by
putting version blocks there and using the OS functions.

Would be appreciated, it definitely makes sense to add them! It's just
for historic reasons that it is this way (resolveHost was added after
connectTCP et al.)

Ah that makes sense. Thanks for taking a look! Any reasonable work-around in the meantime that you can think of? It seems all you can get out of a NetworkAddress is OS-specific handles and there doesn't seem to be a way to feed that into the relevant TCPConnection framework that I can see.

On Mon, 27 Jan 2014 20:34:56 GMT, Stefan Koch wrote:

Ah that makes sense. Thanks for taking a look! Any reasonable work-around in the meantime that you can think of? It seems all you can get out of a NetworkAddress is OS-specific handles and there doesn't seem to be a way to feed that into the relevant TCPConnection framework that I can see.

Sorry you to wait until tomarrow noon. Then I hopefully know more ...
should not be too much trouble to find a workaround.

One possibility would be to use std.socket.Address.toAddrString (NetworkAddress needs to be converted to an InternetAddress or Internet6Address).

My first reaction was "vibe.d should really use std.socket.Address instead of its own NetworkAddress". But then I realized that it is a class. But network addresses definitely have to work without any kind of GC/heap allocations, so this unfortunately is not really an option. But at least there could be a NetworkAddress.toAddress function that performs the conversion in a convenient way.