Forums Feature Suggestions /sockudp and localhost

Not sure if it's a bug so here the suggestion, we can /sockopen to localhost, but can't /sockudp to localhost :
It would make sense for /sockudp to also accept localhost as an ip address

This is not a bug, as it is documented behavior. From /help /sockudp:


I'd guess it's a matter of implementation complexity: if mIRC were to accept hostnames there, it would have to resolve the host while keeping the packet around for sending when the resolution succeeded. It is much easier to simply send the packet rightaway, and not keep track of these things. Of course mIRC can be changed to support hostnames here, but is it really worth it?

I'm not sure about the complexity since it's done for tcp but you might be right.
I have a client and a server where only the server needs to open a tcp port and a udp port.
Since the server can run with any tcp/udp ports, it's up to the client to specify an ip address and a tcp port, the client first connect to the server with tcp and then udp is done internally (the server send the udp port).
In this case when the client want to send a packet, it will use the ip address specified when connecting with tcp, and it will fail if localhost has been used.
I could do $iif(address == localhost,127.0.0.1,$v1) but it doesn't seem to be the good solution so imo, yes.

It's not done for TCP. TCP uses /sockopen to statefully set the remote host for the remainder of the connection. Namely, you don't /sockwrite <hostname> <data>, the hostname is already stored in the sockopen, with TCP connections. This is unlike UDP, which is not tied to a specific remote host and does need to know about the dest. IP for every packet.

Something to note: if this were to be supported and you used it, your script would become slower, since mIRC would have to resolve the <host> parameter everytime it executed. Again, this is unlike TCP, which resolves the remote host to an IP upon /sockopen. This of course assumes mIRC would not cache lookups, which I don't think it should be doing. One of the first things you'd do to optimize the script would be to remove the inline host resolution anyway, so it seems unnecessary to me.

True but :
The -k switch of /sockudp let you use the same "connexion" everytime, so the cache is sort of already supported internally, this would not make my script slower.

Not the same thing. -k only performs a bind on the local port and keeps the socket open. It does not remember the remote ip/port, and that is not its purpose. Many scripts that use sockudp -k listen for packets from varying remote hosts and can respond to any arbitrary remote host within the course of a connection, aka. the .saddr can change between UDPREAD events. The sockudp port bug that you recently reported summarized this state of affairs quite well.

Hum that's right, I'll use that $iif if I want to support localhost then