在TCP连接的端口上发送UDP数据包[关闭]

Question

I have a Golang TCP server, i.e. net.TCPConn, connected on a port which, in addition to a TCP stream, also has to receive UDP packets and respond with UDP packets. The incoming UDP packet pops out at the server (from a net.TCPConn.Read()) but I can't figure out how to send a UDP packet back again. All of the UDP write methods apply only to net.UDPConn. net.UDPConn.WriteMsgUDP() tantalisingly talks of whether it is applied to a connected or a non-connected socket, but I can't figure out how to derive net.UDPConn from net.TCPConn; I've tried casting net.TCPConn to net.UDPConn but that causes a panic.

What is the correct way to do this?

FYI, I do have a UDP listener open on the same port ('cos the client at the other end can chose to operate in completely connectionless mode) but since, when the socket is connected, the UDP packet arrives at the TCP server rather than the UDP server, I'd like to send the UDP response back down the same hole, rather than having to mix the two up in some unholy manner. Or is unholiness the answer?

EDIT: a word on the system design here: the purpose of this UDP packet is to test the connection on this socket (the server simply echoes it back). The socket is a [hopefully] established SSH port-forwarding tunnel, hence I don't want to use another socket as this wouldn't test what I'm trying to test (i.e. that both the socket and the SSH tunnel are open; it is a shortcoming of SSH port-forwarding tunnels that, since the application makes a connection to localhost, the socket will report connected immediately, even if the server isn't actually connected at the time). The SSH tunnel otherwise carries a stream of TCP traffic and I specifically want to use UDP for this as I don't want my UDP connection test to be stuck behind the queue of TCP traffic; timing is important in this application and the UDP packet carries timestamps to measure it. Sending a UDP packet on a connected socket is a valid sockets operation, Go must have a way to do it...?

Answer 1

After a discussion on the Golang forums all has become clear.

@JimB is quite right that you cannot send a UDP packet on a TCP port. The reason I thought this was possible is that the definition of sendto() says:

If sendto() is used on a connection-mode (SOCK_STREAM, SOCK_SEQPACKET) socket, the arguments dest_addr and addrlen are ignored (and the error EISCONN may be returned when they are not NULL and 0), and the error ENOTCONN is returned when the socket was not actually connected.

...and when I called sendto() on my TCP connected port the data I sent did indeed turn up at my Golang net.TCPConn end-point. However, what is happening in this scenario is that, under the hood, sendto() has effectively become an alias for send() and, despite calling sendto(), the data sent is actually being transported in a TCP packet and not a UDP packet at all. This was proved by using netcat -u $host $port to send UDP traffic to the server and netcat $host $port to send TCP traffic to the server: the former did not produce any data at the net.TCPConn end-point while the latter did.

The correct way to do this is for the client to open a TCP and a UDP socket to the server on the same port at the same time while the server, likewise, listens simultaneously for TCP and UDP "connections" (the UDP connection is not a connection at all of course, it is simply an association with a local port number) on the same port. The TCP server then handles my stream and the UDP server handles my UDP test/measurement packets, both down the same SSH port forwarding tunnel.