UDP socket Read timeout

2,673 views
Skip to first unread message

GGGO

unread,
Nov 29, 2011, 1:44:24 PM11/29/11
to golang-nuts
I have this in a goroutine :
con, err := net.Dial("udp", "ipaddress:8080")
con.SetReadTimeout(1e8)
_, err := con.Write([]byte(requestValue))
for {
select {
case <-tick:
// resync object
default:
//con.Write([]byte("")) // to permit con.Read to detect error
_,err = con.Read(responseValue)
// other
}
}

I know that UDP connection cannot be monitored like TCP. But if I
close server listenning at 8080, _,err = con.Read(responseValue) never
detect error, even if con.SetReadTimeout is set.
So loop "for" continue to loop forever.
The only solution I have found is to put con.Write([]byte("")) just
before _,err = con.Read(responseValue) and now err of con.Read() say
me something.
I don't like the fact that server is overloaded by con.Write, even if
it's a little packet.
Is there another way to do that ?
Thanks.

Russ Cox

unread,
Nov 30, 2011, 4:07:47 PM11/30/11
to GGGO, golang-nuts

I may not completely understand, but part of the deal with UDP
is that you don't get to know whether there is a machine on the
other end. So a UDP Read only has two possible return values:
(1) I got a packet, or (2) I hit the timeout. Are you saying that
the udp Read does not report a timeout? That would be a bug.
But if you are asking for a 3rd possible return value, that's not
possible. Apologies if I have misunderstood the question.

Russ

GGGO

unread,
Nov 30, 2011, 5:34:30 PM11/30/11
to golang-nuts
Hi,
you're right about 3rd possible value.
timeout on read always work but it just report this all time: 'read
udp ipaddress:port: i/o timeout'.
Even if connection is closed.
So the only solution I have found is to force a writing on socket, and
now "err:=con.Read()" return this : 'read udp ipaddress:port:
connection refused'
It's the only solution have found, maybe there is another better.

But what I don't understand, is why con.write help con.Read to detect
'connection refused', is it not possible to put this check in Read ?

Thanks


On Nov 30, 4:07 pm, Russ Cox <r...@golang.org> wrote:

Russ Cox

unread,
Nov 30, 2011, 7:01:31 PM11/30/11
to GGGO, golang-nuts
Could you create a short standalone program
that I can compile that demonstrates the problem?

Thanks.
Russ

6355...@qq.com

unread,
Nov 30, 2011, 8:38:23 PM11/30/11
to golang-nuts
for UDP, it's impossible to put that check in Read.

you said you don't understand why con.Write help con.Read to detect
'connection refused'. This is because, con.Write() will send a packet
to the server, but the server is shutdown, so the server's OS will
send a 'connection refused' RST packet to your client.

Kyle Lemons

unread,
Nov 30, 2011, 8:42:54 PM11/30/11
to GGGO, golang-nuts
Are you trying to get the Read() to return when you call udpsock.Close() and it won't?  You also seems to indicate that after calling Close(), the read timeout no longer fires.  If this is the case, as rsc said, please post a minimal reproducing example for us to peruse.

Mikio Hara

unread,
Nov 30, 2011, 8:54:29 PM11/30/11
to GGGO, golang-nuts
Hi,

On Thu, Dec 1, 2011 at 7:34 AM, GGGO <ggco...@gmail.com> wrote:

> But what I don't understand, is why con.write help con.Read to detect
> 'connection refused',

When the UDP packet you sent from a client arrived at a server,
IP protocol family guys inside server do start packet delivery
process: have a look at customer book, realize that there is no
customer on a protocol, port corresponding to the incoming packet
and finally report ICMP dst-unreach/port-unreach error to the client.

The client could realize that seems like the server won't talk anymore
by that ICMP error notification.

> is it not possible to put this check in Read ?

Mostly UDP based protocols implement its own dead peer detection
mech such as heartbeat, keepalive, etc because that's the UDP way.

If you really need a lightweight but a bit more reliable datagram-based
vehicle you can use DCCP instead of UDP. Go standard packages
not support DCCP yet but it wouldn't be tough work I think.

GGGO

unread,
Nov 30, 2011, 9:28:06 PM11/30/11
to golang-nuts
Thanks everyone !
My question is answered !

GG

On Nov 30, 8:54 pm, Mikio Hara <mikioh.mik...@gmail.com> wrote:
> Hi,
>

Reply all
Reply to author
Forward
0 new messages