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 <kra...@skepticism.us> wrote: > > On Sun, Jun 21, 2020 at 5:11 PM <hardconnect....@gmail.com> 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.
