Is there a need for goroutine for a UDP server?

blov · · 346 次点击    
这是一个分享于 的资源,其中的信息可能已经有所发展或是发生改变。
<p>I&#39;m not sure if the question makes sense but since there is not state in UDP, for a server just listening for incoming data w/o writing a for loop should be enough right?</p> <hr/>**评论:**<br/><br/>TheMerovius: <pre><p>It might make sense, to decouple the receiving/parsing of packages from the processing. For example, if you have a bittorrent client that needs to receive a package and write a chunk to disk - it might turn out, that a simple receive-write-loop is not very performant in this case, as you need to write for a disk-write to succeed before reading another package and the other way around. Decoupling that into separate goroutines might make sense.</p> <p>I don&#39;t think it depends very much on UDP/TCP whether concurrency is appropriate, but mostly on what you are trying to do with the data. If it&#39;s a problem that can well be abstracted into separate concurrent processes, you should probably still do it :)</p></pre>kunos: <pre><p>If the server really doesn&#39;t do anything other than waiting for a packet then yes. In Go sockets cannot be made non blocking, that&#39;s why most people use a go routine and channel to receive.</p></pre>brentrowland: <pre><p>For something simple, like a message multiplexor (think chat server), a single thread is quite often more than enough. There is a certain amount of queuing in your network stack that is more than adequate when each packet is self-contained and handled quickly. However, should your processing involve blocking operations, such as writing to a disk with unpredictable latency (think Amazon EBS or an external USB drive that may need to spin up) or calling out to web service, then some kind of concurrency is warranted.</p></pre>
346 次点击  
加入收藏 微博
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传