Netty vs. NIO2 vs ...? for mud

Networking & Multiplayer
#1

hi,

I’m figuring out how to write a mud, and Netty sounded like a good library. However in reading about that I learned of NIO2 (new with Java 7). There are some articles out there about NIO2 but I’m wondering if anyone here has some thoughts or experience on using NIO2 vs. Netty (or similar single-threaded async libraries).

Of course NIO is an option but since I’m using Java 7 already I thought why not NIO2.

There was this thread here, http://www.java-gaming.org/topics/java-nio-unblocking-server-with-multiple-clients/20630/msg/167616/view.html#msg167616 , but it is from a few years ago so maybe there are some fresh perspectives.

Thanks for any help.

#2

Netty is a layer on top of NIO. NIO2 is just some extra stuff for filesystem operations, including something a whole lot more sane than java.io.File. Netty’s a fine choice for writing network servers, but if I were going to make a modern MUD, I’d probably just make it all web-based and do it all with ajax. A jetty server out of the box could handle and retire more commands as individual http requests than any MUD ever dreamed of a decade ago using telnet. Maybe I’d go with websockets, but probably not even that.

#3

I think it might be overkill to use NIO for a MUD. How about normal blocking I/O? You can get decent performance out of those. NIO was designed for waaaaay more connections than I think you would ever need.

EDIT: This wasn’t the question in the OP. My apolegies.

#4

Thanks for the replies. I think I’m confused about some of the terms here. In my reading I see a lot about asynchronous operations (like those supported by NIO2). I always equated this with the classic multiplexed single-threaded server design (like you see in a lot of old muds that use select() and so on).

However now it seems like async and single-threaded multi-plexed are two different things. Can anyone comment as to why an async design might or might not be better for a mud?

#5

You can do asynchronous I/O with thread-per-connection and you can do fully blocking I/O with select. It’s just that 1-1 threads makes blocking easy, and blocking on select is only useful when nothing else is running, so those designs tend to find their level with the API style that is easiest to work with.

Asynchronous just means you don’t want for I/O to complete, but someone else is waiting for it to complete instead, whether its a background thread polling a set of fd’s, or the OS’s internal I/O scheduler taking care of it directly. When some I/O is completed (e.g. a full line or packet or whatever is read or written), then that background routine notifies you through a callback. It’s stringing callbacks together like that that makes an API asynchronous, not necessarily the I/O primitives used under the surface. Asynchronous just means you’re not waiting for anyone to finish, but you’ll let them call you back when the result’s ready.

MUDs almost exclusively use classic select()/poll(), which is the basic design of NIO, yes. With Netty, that select loop tends to run in its own thread, freeing you to write code that’s purely based on callbacks, which again is the essence of an asynchronous API.

#6

There is support for AIO sockets in Netty 4.0.