This is “by design”.
First, it helps measuring latency between client himself and Noobhub server. Second, it saves couple of lines of code 
Anyway, this can be easily changed in server code, if you want. But Im not sure if that will really improve performance. Better conduct some tests before.
(1) I have seen a statement that Noobhub uses 8k buffer for one connection. Therefore, if I have a 2G RAM server, the calculation is like
(2G - some memory used by the system, say 256K) / 8K ~= 220 connections
Is this kind of calculation correct? If my game is a head-to-head fighting game, it means 110 concurrent games I can host? Or how to do the calculation (roughly)?
(2) I also saw couple of times that Noobhub could support 1 million connections if a server is fine tuned, I am wondering what the server configuration (how much CPU & RAM) would be (roughly)?
Youre mistaken by a 1000
(2*1024*1024*1024) / (8*1024) = 262144
Given the fact thet some multicore nodejs servers can handle up to million concurrent connections, that seems fair.
In real life, you will sooner face the fact that latency has grown too much (i.e. nodejs will spend a lot of CPU time just to send mesages to channels) than the fact that youre out of RAM for storing connections.
Oh, and for the second question.
The fine-tuned test configuration which really handled 1 million of concurrent connections was: Core i7-2600 Quad, 16Gb RAM
Sorry about the mistake. I was wondering something must be wrong!
I am planning to send out a message every 30 milli-second for a client (to sync client inputs), do you think it’s something totally reasonable? Anything I should be wary of?
@joe528, I’m guessing you are building a realtime multiplayer, with 33 HZ ticks.
TCP is not the best option for this, I’d recommend UDP.
Imagine the slight network fault. TCP will give you a huge lag, since messages are stacked in TCP/IP stream buffer, and they will wait until the protocol will resend broken packets, and only then will give out all the stacked messages in stream.
For UDP, you just skip broken or undelivered packets (which is one packet per one tick), and go on receiving ticks.
With realtime multiplayer based on ticks this is important.
So my suggestion is you test Noobhub and see if it will work fine for this.
Once you will start experiencing huge lags due to network faults (if any), its possible to rewrite Noobhub to utilize UDP.
Its not hard, and I would help with it (Im itchy to do this for a long time).
thanks for the comment. I will try it out first with TCP and let you know how it goes. Since my client will simply wait if a remote packet does not come for the current execution turn, so I am not sure how much impact would it be when some networking problem happens as you described. Maybe just halting a bit and catch up without problem? I will give it a try.
I have no experience in node.js though, your help to make it UDP compatible is very much needed (to stop the itch too :))
by the way, the site
seems not running since 24 hours ago… it’s still down and you might want to take a look…
Hi,
Seems to be working now. Not sure what the issue was.
Best.
I have tested sending a packet out every 30ms. There are two players sending to each other. I have put them there for an hour, and I can still play it without any problem after 1 hour.
Questions:
(1) As you said “Imagine the slight network fault. TCP will give you a huge lag”… how to test this situation? What else can I test further except putting it there for an hour?
(2) This is only for one game, two connections. I am wondering how to estimate the server capacity to handle FPS-kind of games (sending a message out on each frame)? Earlier when we discuss possible number of concurrent connections a server can handle, we just divide the total memory by 8k to get a rough number. But the scenario is not sending message out as crazy as this, right? If a client send out a message every 30ms, is there any way to estimate how many concurrent connections a server can handle before it goes to live?
(3) I think I should also give UDP a try since the game is totally fine for packet loss & unordered packets. And changing to UDP should give the server lighter processing load?
Sending out a packet every 30ms or 100ms is working in Wifi but it’s not working in 3G network.
I am wondering if changing to UDP can improve things or I have to give up the idea.
(1) this should be a very rare situation, when you occasionally get a time lag of 100-200 ms instead of 30 ms.
(2) the only way is to increase gradually CCU (concurent connections) which send data, and measure the degradation of latency. I can assure you that 2k CCU wont give any latency degradation (battle-tested on production recently by one folk who uses Noobhub)
(3) not sure if lighter processing load will be even noticeable, sincse TCP/IP is also packets in the core
As for 3g, I would say the bigger issue is increased overal latency, for both protocols, so UDP is not a silver bullet. This is where latency-compensation and prediction algorythms come to play, and game-feel would totally depend on them.
And I didnt get it, hows its not working?
When I say “it’s not working in 3G network”, I mean it seems the packets are received with a lot of latency, probably over 3 seconds and “unstable”.
The character in the game is either moving slowly or gets stuck for many seconds and then move a few frames.
Can I assume there will be NO packet loss at all when using Noobhub (due to TCP/IP) ?
Absolutely
I don’t want to create rooms in advance to ask players to join because I want to match them randomly. For example, a player can simply click a button “Fight” and the system will match two players who click “Flight” around the same period of time.
How to achieve this with Noobhub?
The algorith is the same as with lobby “rooms” which was discussed before, you just dont show the users all the work with lobby and rooms. You silently do the job of asking “who wants to play?” in lobby channel, and connect everyone wiling to play in another channel. And thats it. Users dont see all the background work.
I found when a client subscribes a channel and sends a notification, the client will receive his own message too.
Assume there are two players in a room… if player A sends “hello”, the server receives it and the sends “hello” to both player A and both player B, is it correct?
I am wondering if sending to player A should be passed to save some network bandwidth? (It’s my main concern because I intend to send one message out every 30ms, which means 30 messages per second… or maybe this shouldn’t be a concern at all?)
Maybe there is some advantage about the client getting his own message when implementing a multiplayer game via a sub/pub model?
Sorry for newbie questions. I have read many articles on the web but the progress is kind of slow.
This is “by design”.
First, it helps measuring latency between client himself and Noobhub server. Second, it saves couple of lines of code
Anyway, this can be easily changed in server code, if you want. But Im not sure if that will really improve performance. Better conduct some tests before.
(1) I have seen a statement that Noobhub uses 8k buffer for one connection. Therefore, if I have a 2G RAM server, the calculation is like
(2G - some memory used by the system, say 256K) / 8K ~= 220 connections
Is this kind of calculation correct? If my game is a head-to-head fighting game, it means 110 concurrent games I can host? Or how to do the calculation (roughly)?
(2) I also saw couple of times that Noobhub could support 1 million connections if a server is fine tuned, I am wondering what the server configuration (how much CPU & RAM) would be (roughly)?