Is vibe-d a good fit for my project?

Permalink: HTTP NNTP

Kelet

Posted Sat, 08 Feb 2014 18:19:11 GMT

Reply

Hello again,

I've been asking a lot of newbie questions lately, and I appreciate those who have answered the questions quite thoroughly. The reason I've been asking these questions is because I'm looking to create a server for a real-time 3D video game in D (think Quake 3). The last time I attempted this, my server was hopelessly single-threaded and synchronous, so this time I'm looking to find a better approach.

The idea behind the server is quite simple:

Client sends the server a message, such as 'shoot gun' or 'move forward'
The server takes this message and sends it to be processed by a thread which has the least work (a metric which is often hard to figure out)

I've got a reasonable idea on how to set up a fine-grained system of locks for this architecture, and it allows for good load balancing and avoiding a set number of threads. Some server architectures go for one thread for collision detection, one thread for ..., etc. which creates a set number of threads and poor load balancing, which is what I'm looking to avoid.

However, it looks like vibe-d may not be a good candidate for this kind of architecture:

The server operates on UDP, and unlike TCP, I don't have a bunch of connections to worry about. I just accept datagrams. It's enough to have one listenUDP.
Each message received by the server will create an operation that is quick (no yielding) and needs no sleeping. Such as tracing a bullet path or changing an entity's location.
There is little to no I/O going on beyond receiving UDP datagrams.

Now as I understand, compared to just throwing around function pointers/delegates, the advantage of using Fibers in this architecture is that it makes it easier to debug.

Can someone clarify my assumptions or recommend why vibe-d might be a better fit than I think, or recommend another approach?

Thanks,
Kelet

Re: Is vibe-d a good fit for my project?

Permalink: HTTP NNTP

Dicebot

Posted Sat, 08 Feb 2014 22:50:31 GMT in reply to Kelet

Reply

Have you read series of articles from extrawurst about his experience of using vibe.d for game server? http://forum.dlang.org/post/dxcruptyfxsaauihzknw@forum.dlang.org

I don't think there are many straightforward advantages from vibe.d architecture for your specific use case but there are no drawbacks either. It is pretty simple and you get some utility modules implemented on vibe.d base. Also I doubt using worker thread with naive locking system will do any benefit, can possibly be even worse than simple single-threaded approach. Multithreading is good when you can minimize locking as much as possible.

Re: Is vibe-d a good fit for my project?

Permalink: HTTP NNTP

Kelet

Posted Sun, 09 Feb 2014 01:51:13 GMT in reply to Dicebot

Reply

On Sat, 08 Feb 2014 22:50:31 GMT, Dicebot wrote:

Have you read series of articles from extrawurst about his experience of using vibe.d for game server? http://forum.dlang.org/post/dxcruptyfxsaauihzknw@forum.dlang.org

Yes, I have read much of it, and it's good stuff. Need to catch up on parts 3/4 though. His game server is a more suitable candidate for vibe-d as he uses websockets which has persistent connections and streams, whereas my game server will use UDP which does not.

I don't think there are many straightforward advantages from vibe.d architecture for your specific use case but there are no drawbacks either.

For the most part, that's what I came to the conclusion of.

Also I doubt using worker thread with naive locking system will do any benefit, can possibly be even worse than simple single-threaded approach. Multithreading is good when you can minimize locking as much as possible.

The lock system I have in mind should only have minimal waiting. It's not naive. However, it's not implemented yet either – it mainly centers around the receiving a packet from a client should only be able to spawn tasks that modify data particular to that client.

I've thought about it a bit, and at least for the initial stages, I think I'm just going to create an interface for implementing backends for the task spawning system. I'll implement my own back ends: One synchronous, one using function pointers/delegates plainly, one using fibers, and one using vibe-d. I'm unsure if for the non vibe-d backends whether it is worth using libevent for UDP, though. It seems like it is much more useful for things like TCP or monitoring files.

Re: Is vibe-d a good fit for my project?

Permalink: HTTP NNTP

Stefan Koch

Posted Sun, 09 Feb 2014 12:11:05 GMT in reply to Kelet

Reply

On Sun, 09 Feb 2014 01:51:13 GMT, Kelet wrote:

I've thought about it a bit, and at least for the initial stages, I think I'm just going to create an interface for implementing backends for the task spawning system. I'll implement my own back ends: One synchronous, one using function pointers/delegates plainly, one using fibers, and one using vibe-d. I'm unsure if for the non vibe-d backends whether it is worth using libevent for UDP, though. It seems like it is much more useful for things like TCP or monitoring files.

Why would you create multiple backends ?
I'd say prototype it in vibe.d and if it is not fast enough profile it, fix it and send pull requests to vibe.d ....
That way everybody useing vibe.d can be as fast as you

Re: Is vibe-d a good fit for my project?

Permalink: HTTP NNTP

Dicebot

Posted Sun, 09 Feb 2014 15:13:07 GMT in reply to Kelet

Reply

On Sun, 09 Feb 2014 01:51:13 GMT, Kelet wrote:

worth using libevent for UDP, though. It seems like it is much more useful for things like TCP or monitoring files.

UDP vs TCP is completely irrelevant here. It is all about having I/O during request processing and/or long computations. Async approach simply provides very efficient scheduling of CPU time for such cases.

Re: Is vibe-d a good fit for my project?

Permalink: HTTP NNTP

Etienne

Posted Sun, 09 Feb 2014 19:27:26 GMT in reply to Kelet

Reply

On Sat, 08 Feb 2014 18:19:11 GMT, Kelet wrote:

Now as I understand, compared to just throwing around function pointers/delegates, the advantage of using Fibers in this architecture is that it makes it easier to debug.
Can someone clarify my assumptions or recommend why vibe-d might be a better fit than I think, or recommend another approach?

Fibers are most useful when you're waiting to receive or send data with any i/o operation. Even if it takes 1 msec to send your response data to the client, instead of the thread being returned to the O/S while data is being sent, it'll return to the application's event loop for other tasks / fibers and send more bytes on the next run of the fiber. A lot of web servers create a new process in the kernel for each web request in order to solve this but it uses more memory and it's also more segmented (you can't benefit easily from shared memory because the processes are segmented).
Fibers make it possible to read/write to the same in-process memory, while other systems could have to use some sort of IPC for it.

Multi-threading request handling isn't the most interesting part here because if it were single-threaded, you could still start a thread to run long operations and yield the fiber to handle another request. I can't imagine saturating all the CPUs with requests, the bottleneck would have to be somewhere else. It sounds like your collision detection algorithm could pull most of the advantages of multi-threading - if you write an efficient algorithm that distributes the operations evenly to all CPUs, the latency would be very low, but you'd still have to yield the fiber after starting this operation. The fiber that handles the web request / which is waiting for an answer won't block other requests from coming in and being handled while it's yielded. You could even call a C library that already has the optimal source code for this if you wanted, you could run the operations in openCV through a new task and yield or such, you'd reduce latency to a minimum.

Re: Is vibe-d a good fit for my project?

Permalink: HTTP NNTP

Etienne

Posted Sun, 09 Feb 2014 20:15:35 GMT in reply to Etienne

Reply

On Sun, 09 Feb 2014 19:27:26 GMT, Etienne wrote:

you could run the operations in openCV through a new task and yield or such, you'd reduce latency to a minimum.

Scratch that, you would probably make best use of futures for this purpose, with worker tasks that start fibers in a separate thread pool that has its own event loop (not related to that which handles the web requests). My idea of futures would allow the web request fiber to receive / send partial answers by capturing ranges.

I think every part of this would need to be built on top of vibe.d currently. https://github.com/rejectedsoftware/vibe.d/issues/490

Otherwise the only way you wouldn't block the thread that handles web requests is by yielding periodically during the thread collision algorithm. In any case, there's lots of flexibility.

Re: Is vibe-d a good fit for my project?

Permalink: HTTP NNTP

Stephan Dilly

Posted Mon, 10 Feb 2014 09:08:35 GMT in reply to Kelet

Reply

On Sun, 09 Feb 2014 01:51:13 GMT, Kelet wrote:

On Sat, 08 Feb 2014 22:50:31 GMT, Dicebot wrote:

Have you read series of articles from extrawurst about his experience of using vibe.d for game server? http://forum.dlang.org/post/dxcruptyfxsaauihzknw@forum.dlang.org

Yes, I have read much of it, and it's good stuff. Need to catch up on parts 3/4 though. His game server is a more suitable candidate for vibe-d as he uses websockets which has persistent connections and streams, whereas my game server will use UDP which does not.

I am not yet finished with Part4. Waiting for approval of the dconf talk now.
By the way, I am not using websockets and persistent connections. I am using long pulling but I don't know how UDP would be less appropriate for vibe.d ?