UDP server question?

[ish]

The following server code has a problem. The write by server to
connection always fails.
I have not been able to find the solution.
--
package main

import (
"fmt";
"net";
"os";
"strings";
)

func main() {
var buf [1000]byte;
sout := "The answer";
bout := strings.Bytes(sout);

laddr, err := net.ResolveUDPAddr("127.0.0.1:6854");
if err != nil { fmt.Println("Resolv.."); os.Exit(1); }

c, erl := net.ListenUDP("udp", laddr);
if erl != nil { fmt.Println("Listen.."); os.Exit(1); }

n, erd := c.Read(buf[0:128]);
if erd != nil { fmt.Println("Read.."); os.Exit(1); }
fmt.Println("Read: ", n);
fmt.Println("Writing: ", len(bout));
_, erw := c.Write(bout); //fails
if erw != nil { fmt.Println("Write.."); os.Exit(1); }

fmt.Print("Main stops\n");
}
--
-ish

[Ian Lance Taylor]

ish <ishwar...@gmail.com> writes:

> The following server code has a problem. The write by server to
> connection always fails.
> I have not been able to find the solution.

> _, erw := c.Write(bout); //fails
> if erw != nil { fmt.Println("Write.."); os.Exit(1); }

If you change this to

if erw != nil { fmt.Println("Write..", erw); os.Exit(1); }

then it will print

Writing: 10
Write.. write udp:127.0.0.1:6854->: destination address required

In other words, for a listening UDP connection, you need to call
WriteTo, not Write.

Ian

[ish]

On Nov 27, 8:52 pm, Ian Lance Taylor <i...@google.com> wrote:

For using WriteTo(), server needs the remote end-point address, which
can only returned by
ReadFrom() and ReadFrom() is non-blocking which is probably not the
way to go on server
side (also to ReadFrom() on server to work, client has to use WriteTo
()...).

Am I missing something?

n, radr, err := c.ReadFrom(&buf); // is non-blocking, needs polling?

then one can use

n1, erw := c.WriteTo(buf[0:n], radr);

-ish

[Ian Lance Taylor]

ish <ishwar...@gmail.com> writes:

> On Nov 27, 8:52 pm, Ian Lance Taylor <i...@google.com> wrote:
>>
>> In other words, for a listening UDP connection, you need to call
>> WriteTo, not Write.
>
> For using WriteTo(), server needs the remote end-point address, which
> can only returned by
> ReadFrom() and ReadFrom() is non-blocking which is probably not the
> way to go on server
> side (also to ReadFrom() on server to work, client has to use WriteTo
> ()...).

ReadFrom is not non-blocking. Is there some documentation which makes
you think that it is?

> Am I missing something?
>
> n, radr, err := c.ReadFrom(&buf); // is non-blocking, needs polling?
>
> then one can use
>
> n1, erw := c.WriteTo(buf[0:n], radr);

Right, do that.

Ian

[ish]

On Nov 28, 8:46 pm, Ian Lance Taylor <i...@google.com> wrote:

> ish <ishwar.rat...@gmail.com> writes:
> > On Nov 27, 8:52 pm, Ian Lance Taylor <i...@google.com> wrote:
>
> >> In other words, for a listening UDP connection, you need to call
> >> WriteTo, not Write.
>
> > For using WriteTo(), server needs the remote end-point address, which
> > can only returned by
> > ReadFrom() and ReadFrom() is non-blocking which is probably not the
> > way to go on server
> > side (also to ReadFrom() on server to work, client has to use WriteTo
> > ()...).
>
> ReadFrom is not non-blocking. Is there some documentation which makes
> you think that it is?

When the server is run without polling it terminates right away (does
not wait for
a client to connect).

-ish

[MIURA Masahiro]

On Nov 30, 1:25 am, ish <ishwar.rat...@gmail.com> wrote:
> > ReadFrom is not non-blocking.  Is there some documentation which makes
> > you think that it is?
> When the server is run without polling it terminates right away (does
> not wait for
> a client to connect).

I had the similar non-blocking behavior with ReadFrom.

BTW, you can use ListenPacket instead of ResolveUDPAddr / ListenUDP
combo.
http://golang.org/pkg/net/#PacketConn.ListenPacket

[Ian Lance Taylor]

Can you show an example of what you mean?

Ian

[Russ Cox]

> I had the similar non-blocking behavior with ReadFrom.

This was a bug (#153), fixed in revision 4087 (d0ac530ee1e2).
If you still see the behavior after running

cd $GOROOT
hg pull
hg update release.2007-11-17
cd src
./all.bash

please post a test program and commands to demonstrate the
behavior.

Thanks.
Russ

[ish]

After the hg update release.2009-11-17, the server does block on
c.ReadFrom() call

Thanks,
-ishwar

[MIURA Masahiro]

On Nov 30, 2:20 am, Russ Cox <r...@golang.org> wrote:
> > I had the similar non-blocking behavior with ReadFrom.
> This was a bug (#153), fixed in revision 4087 (d0ac530ee1e2).

Looks like I've been hit by "need to run all.bash twice" bug.
Minutes ago I ran it twice, and now ReadFrom() blocks.

[Sonia Hamilton]

There's an example in a library I'm using at the moment, for doing SNMP calls - https://github.com/soniah/gosnmp/blob/dev/gosnmp.go

Whether or not it's a _good_ example is debatable :)

Sonia

[Jim Teeuwen]

This may be of some help: http://jan.newmarch.name/go/

On Tuesday, September 18, 2012 5:51:07 AM UTC+2, melissa...@gmail.com wrote:

do any of you know of a good site that has examples on when and how to use the udp functions such as ResolveUDP, DialUDP, etc.? i've been reading the golang.org/pkg pages and i don't quite understand how to use them.

Thanks!

[Guillermo Estrada]

This thread is really old, but I'm trying to write an UDP server and from what I'm getting (Go 1.1 x64_86 Windows)  *UDPConn.Read() blocks, while *UDPConn.ReadFrom() and *UDPConn.ReadFromUDP() are non-blocking. A simple example would be:

package main

import (

  "fmt"

  "net"

)

func main() {

  addr, err := net.ResolveUDPAddr("udp",":3000")

  if err != nil {

    panic(err)

  }

  sock, err := net.ListenUDP("udp", addr)

  if err != nil {

    panic(err)

  }

  buffer := make([]byte, 1024)

  for {

    size, err := sock.Read(buffer)

    // size, address, err := sock.ReadFrom(buffer) <- This starts printing empty and nil values below immediatly

    if err != nil {

      panic(err)

    }

    fmt.Println(buffer, size, err)

  }

}

If someone could point me to what I'm doing wrong It would be wonderful, if so, how can I get the address from Read() that is the one blocking.

On the other side I get the "More data is available" error while using Read() even with a 1KB buffer while testing with a command line client.

[Dave Cheney]

Your commented out line returns three values, what is the value of the second return value ?

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Guillermo Estrada]

As far as I'm concerned it should be the address of the connection that I need to reply to. But Read() just return 2 values (no address), and ReadFrom() or ReadFromUDP() are not blocking for me.

[Dave Cheney]

Yes, but what value is returned. I'm trying to figure out if there is some random process on your machine (you are binding to *:3000) spamming that port. 

Can you please post some output logging all three values from ReadFrom.

[Guillermo Estrada]

I tried with binding first to '127.0.0.1:3000' and first time reported nil values on the address (a lot of times). I just recompiled on another machine and tested running (1.1 windows x64 too) and it is blocking now. I should just wipe installation and reinstall on the first one. Thanks a lot, and sorry for the trouble.

--
"No le digas a Dios lo grande de tu tormenta, mejor dile a tu tormenta lo grande de tu Dios."

[Dave Cheney]

You aren't the first person to report that ReadFrom doesn't block on windows, it is concerning that this function doesn't work reliably on windows. I suggest raising an issue. 

[Guillermo Estrada]

Actually the machine on my work I tested was Windows 7 x64 (non blocking), the one I'm testing in right now is Windows 8 x64(blocking). I'm pretty sure both have Go 1.1 x64 clean installed. I'll check back tomorrow in my work machine and if it still does not block I'll be sure to make the steps to reproduce it and raise an issue. Thanks for all your help Dave.