Proper full duplex TCP communication

[Russ]

Sorry if this question has been asked before (couldn't find anything similar with the search) or if it's way off the mark, but I'm new with go and I'm trying to nail down TCP communication.

I've written a basic server and a basic client; they communicate well enough and while the client cleanly closes its connection the server will continue to listen for new connections.

My question is: are the methods I used accurate enough or is there a better way to handle full duplex communication over a TCP connection? There seems to be tons of options when it comes to reading from streams but this seemed to be the only one that would do what I want. I appreciate any tips or corrections...

My primary concern is the large buffer I used for reading data from the connection; is there a way to make this more efficient built into go or would it be better if I wrote a function that strips off the wasted bytes? What if more than 255 bytes are sent and the data gets truncated? Is there a way to determine the size of the incoming data and allocate properly? I tried to follow the Web.go project as an example but kept getting lost trying to follow all the structs...

Thanks,

Russ B.

[Andrew Gerrand]

On 17 July 2010 08:23, Russ <russell....@gmail.com> wrote:
> Sorry if this question has been asked before (couldn't find anything similar
> with the search) or if it's way off the mark, but I'm new with go and I'm
> trying to nail down TCP communication.
> I've written a basic server and a basic client; they communicate well enough
> and while the client cleanly closes its connection the server will continue
> to listen for new connections.
> My question is: are the methods I used accurate enough or is there a better
> way to handle full duplex communication over a TCP connection? There seems
> to be tons of options when it comes to reading from streams but this seemed
> to be the only one that would do what I want. I appreciate any tips or
> corrections...
> My primary concern is the large buffer I used for reading data from the
> connection; is there a way to make this more efficient built into go or
> would it be better if I wrote a function that strips off the wasted bytes?

I wouldn't say 255 bytes is a large buffer. Are you concerned that the
Read will block until at least 255 bytes are Read? You can mitigate
this with the SetReadTimeout function:
http://golang.org/pkg/net/#TCPConn.SetReadTimeout

The example you've posted will only read the first 255 bytes, but I
presume you know that. You should write another for loop inside the
main one to Read until the connection closes.

> What if more than 255 bytes are sent and the data gets truncated? Is there a
> way to determine the size of the incoming data and allocate properly? I
> tried to follow the Web.go project as an example but kept getting lost
> trying to follow all the structs...

If more than 255 bytes are sent, you'll need to perform additional
Reads from the connection and Write them back.

I wrote a TCP<->HTTP<->TCP tunnel in Go, which demonstrates some of
this stuff. I wrote it a little while ago, so there are probably
cleaner and more idiomatic ways of doing it, but it's worth checking
out: (client is simpler than server)
http://github.com/nf/gohttptun

Andrew