Hacker News Reader

Comment by bullen | Hacker News Reader

Who uses non-blocking networking on the client?

It's not like you don't have cores/threads for blocking when you just have one server, how many servers are they going to connect to?

Or is this for the Unity server part?

View on HN

From what I've seen, it's a common convention with game development to do non-blocking networking and update your network state every tick of your update loop.

It fits in nicely with how everything else works in your game loop, and means you don't need to deal with marshalling data to/from a dedicated thread.

You should keep the network async. from the rendering yes, but why non-blocking?

Actually, the select() call was blocking. Non-blocking in this context would mean periodically calling select() with a timeout of 0.

Select being blocking is normal, non-blocking IO does not depend on select being non-blocking.

Select returns the list of non-blocking sockets that have data read/write pending.

select() is just a means to multiplex network I/O. It can be either blocking or non-blocking, depending on your application architecture. I have worked on both kinds.

BTW, the sockets themselves don't even have to be non-blocking.

Also, I'd like to stress that the concepts or blocking/non-blocking I/O and synchronous/asynchronous I/O are really orthogonal. You can do synchronous networking with non-blocking sockets and vice versa.

Or to put it another way: depending on the timeout value, select() can achieve blocking or non-blocking I/O on several sockets simultaneously. In both cases, the sockets themselves can be either blocking or non-blocking.

There is no practical difference between blocking on select() for multiple sockets or blocking on recv() for a single socket - in both cases the thread can't do anything else.

> It's not like you don't have cores/threads for blocking when you just have one server

Some platforms don't have these luxuries.

Why blocking?

Because it's simple and on the client that does not have many connections there is no point to use non-blocking just because it's the latest tech.!

Non blocking IO is ancient tech, it is done because spinning up more threads is expensive and makes performance unreliable. Thread overhead is much less of an issue today so just spinning up a new thread and running everything with blocking calls is the modern way of doing things, but many of the idioms for games are from a long time ago when not every CPU was multi core so thread switching overhead was huge and therefore they had to do non blocking IO to run well.

So if your client has one thread for networking why use non-blocking?

The age is relative, sockets are from the 70s, non-blocking is 2000+ and in most languages it's only stable since 2010+.

Overlapped (=async) IO has been in Windows since NT came out, so mid-90s. I don't even know what you mean with "most languages". Most programming languages are only stable since 2010+ anyway, we get more languages every year.

> So if your client has one thread for networking why use non-blocking?

No, the client would have one thread for everything, not one thread for networking. You shouldn't do blocking IO if you only have one thread that also needs to do other things.

Reply on news.ycombinator.com