Re: [go-nuts] Can you have multiple go routines waiting on a socket?
On Sun, Jun 21, 2020 at 8:05 PM Robert Engels wrote: > Most webservers use multiple threads per socket - this is commonly > observed with async IO. IO in Go is async behind the scenes so you don’t > need to worry about this. You probably will use a Go routine to read the > socket; and probably another to do the writing - so you can treat the IO as > synchronous. That is a wonderful aspect of Go. > That is true but it's not clear the O.P. is ready to appreciate that distinction. Note that their question was about having multiple readers running in parallel. Something that, in general, is not safe for TCP connections. It's not safe even if additional constraints, such as fixed size structures, are in effect. That's because TCP does not preserve message boundaries and a given structure might be broken up and received in pieces. Thus resulting in different readers of the socket reading different pieces of the structure. -- Kurtis Rader Caretaker of the exceptional canines Junior and Hank -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CABx2%3DD-3U%3DA0A9%2BO7%2BCAKLUVLA0s7Gn%3DrfGfwxDhu5PHA70_Fg%40mail.gmail.com.
Re: [go-nuts] Can you have multiple go routines waiting on a socket?
Most webservers use multiple threads per socket - this is commonly observed with async IO. IO in Go is async behind the scenes so you don’t need to worry about this. You probably will use a Go routine to read the socket; and probably another to do the writing - so you can treat the IO as synchronous. That is a wonderful aspect of Go. > On Jun 21, 2020, at 7:57 PM, Kurtis Rader wrote: > > On Sun, Jun 21, 2020 at 5:11 PM wrote: >>> Yes, the exact use case I'm thinking of is reading UDP datagrams. I just >>> want to read them as fast as possible then hand them off to other >>> goroutines for further processing. I was just thinking I would get better >>> speed/throughput if I had a couple of go routines listening, waiting to >>> pick up a packet. >> >> What manner of unpredictable behavior do TCP sockets exhibit of you have >> multiple reading processes? Does anyone know how high performance web >> servers deal with this? >> (I'm thinking of Apache/Caddy, etc) > > Web servers don't use UDP. They use TCP which is a stream of bytes without > message boundaries. They also don't have multiple goroutines reading from the > same socket. They bind a socket to an address then listen for incoming > connections. When a connection is established the listen call returns a new > socket over which communication with the client takes place. In a web server > written in Go a goroutine would be spun up to handle communication with that > client. The goroutine that handles new connections immediately goes back to > listening for another connection from a client. > > To answer your question about why what you're trying to do can result in > unpredictable behavior when TCP (SOCK_STREAM) sockets are used consider a > simpler model. Since a TCP connection is just a bidirectional stream of bytes > we can model their behavior using pipes. Consider what happens if you have > one or more processes writing lines (i.e., variable number of bytes > terminated by a newline) into the pipe. Your process has two goroutines each > reading lines from the pipe. Each goroutine processes one line at a time by > reading one byte at a time until it sees a newline. Assume the line "abcd\n" > is written into the pipe. Each goroutine reads one char. This means one of > them will receive the "a" and the other the "b". Oops! It's even worse than > that because depending on which one is first to read another char either of > the goroutines will see the "c". That is obviously a contrived example but > illustrates the problem. > > It's not clear you actually understand the difference between UDP and TCP and > the characteristics of each. I don't know what books or resources are good > references today. Back in the 1990's when I was learning network programming > I used "TCP/IP Illustrated" and "UNIX Network Programming", both by W. R. > Stevens, as well as several other books. > > -- > Kurtis Rader > Caretaker of the exceptional canines Junior and Hank > -- > 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+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/CABx2%3DD_voTyO5jynkx58i-Le5t7d8Ve3qSXy-Xk97gfZCyTspA%40mail.gmail.com. -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/4F0B4332-46B4-4E21-B72B-7D0C7EBD0C57%40ix.netcom.com.
Re: [go-nuts] Can you have multiple go routines waiting on a socket?
On Sun, Jun 21, 2020 at 5:11 PM wrote: > Yes, the exact use case I'm thinking of is reading UDP datagrams. I just >> want to read them as fast as possible then hand them off to other >> goroutines for further processing. I was just thinking I would get better >> speed/throughput if I had a couple of go routines listening, waiting to >> pick up a packet. > > > What manner of unpredictable behavior do TCP sockets exhibit of you have > multiple reading processes? Does anyone know how high performance web > servers deal with this? > (I'm thinking of Apache/Caddy, etc) > Web servers don't use UDP. They use TCP which is a stream of bytes without message boundaries. They also don't have multiple goroutines reading from the same socket. They bind a socket to an address then listen for incoming connections. When a connection is established the listen call returns a new socket over which communication with the client takes place. In a web server written in Go a goroutine would be spun up to handle communication with that client. The goroutine that handles new connections immediately goes back to listening for another connection from a client. To answer your question about why what you're trying to do can result in unpredictable behavior when TCP (SOCK_STREAM) sockets are used consider a simpler model. Since a TCP connection is just a bidirectional stream of bytes we can model their behavior using pipes. Consider what happens if you have one or more processes writing lines (i.e., variable number of bytes terminated by a newline) into the pipe. Your process has two goroutines each reading lines from the pipe. Each goroutine processes one line at a time by reading one byte at a time until it sees a newline. Assume the line "abcd\n" is written into the pipe. Each goroutine reads one char. This means one of them will receive the "a" and the other the "b". Oops! It's even worse than that because depending on which one is first to read another char either of the goroutines will see the "c". That is obviously a contrived example but illustrates the problem. It's not clear you actually understand the difference between UDP and TCP and the characteristics of each. I don't know what books or resources are good references today. Back in the 1990's when I was learning network programming I used "TCP/IP Illustrated" and "UNIX Network Programming", both by W. R. Stevens, as well as several other books. -- Kurtis Rader Caretaker of the exceptional canines Junior and Hank -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CABx2%3DD_voTyO5jynkx58i-Le5t7d8Ve3qSXy-Xk97gfZCyTspA%40mail.gmail.com.
Re: [go-nuts] Can you have multiple go routines waiting on a socket?
> > Yes, the exact use case I'm thinking of is reading UDP datagrams. I just > want to read them as fast as possible then hand them off to other goroutines for further processing. I was just thinking I would get better speed/throughput if I had a couple of go routines listening, waiting to pick up a packet. What manner of unpredictable behavior do TCP sockets exhibit of you have multiple reading processes? Does anyone know how high performance web servers deal with this? (I'm thinking of Apache/Caddy, etc) Thanks! Joe -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/b098a47e-85dd-44fa-bdc7-3b5c0fe5f798o%40googlegroups.com.
