he does not say that the servers crash. He says that they reboot them.
This MIGHT be a faster way to handle a "log in, ill the server process, restart it" version. Sort of "just press the small button in front and things handle themselves". Resetting is way faster than even logging in.
Again looks like a management decision.
TCP can get stuck for around 1.5 minutes under "regular bad" network conditions, and pretty indefinitly under VERY Bad ones (which is more academic).
now, lets see. What about a RTS where one party gets stuck for 1.5 minutes? Ups, thats it. It is still strategy. It all depends on how "time sensitive" this is. And this, btw, is ONE packet getting loist (60 seconds waiting for the packet to arrive, then recovering it).
Now, for UDP - maybe you do not need a confirmation for most data? Like position data - if the next position arrives, you dont need to get the last one confirmed:-)
Sure, as long as you do it on a LAN.
Ridiculous what idiots dont even manage to post here.
IP Multicast does not work on the internet. Why? Because the infrastructure (mainly the routers) do not support it.
Ask you ISP, if you dont believe me.
And next time think first.
Forget RMI/CORBA/DCOM etc. - this is not done for this scenario. MS even has it's own framework (DirectPlay) for handling network code in games.
THe main problem is you DO NOT NEVER EVER want to use TCP:-) It can get sruck, which is a pain in the ass for anything time conservative. No way.
You ahve to use something that is UDP based, and your own layer on top of this.
Regards
Well, then I suggest you start eating your own food.
Write a program that opens 40.000 Threads, and you will see what a memory and resource hog you have.
A therad is pretty heavy - it needs at least it's own stack. Just at 64k per stack, 40.000 therads run you down to a memory use of 2500 Megabyte. Thats around 2.5 Gigabyte of RAM just for nothing.
And the scheduler needs to check them once in a while.
Try it out - and come back whining.
Slashdot Mirror
Can you proove taht the eve-online CLIENT was written in Python? Sounds just way too ridiculous.
he does not say that the servers crash. He says that they reboot them. This MIGHT be a faster way to handle a "log in, ill the server process, restart it" version. Sort of "just press the small button in front and things handle themselves". Resetting is way faster than even logging in. Again looks like a management decision.
TCP can get stuck for around 1.5 minutes under "regular bad" network conditions, and pretty indefinitly under VERY Bad ones (which is more academic). now, lets see. What about a RTS where one party gets stuck for 1.5 minutes? Ups, thats it. It is still strategy. It all depends on how "time sensitive" this is. And this, btw, is ONE packet getting loist (60 seconds waiting for the packet to arrive, then recovering it). Now, for UDP - maybe you do not need a confirmation for most data? Like position data - if the next position arrives, you dont need to get the last one confirmed :-)
Sure, as long as you do it on a LAN. Ridiculous what idiots dont even manage to post here. IP Multicast does not work on the internet. Why? Because the infrastructure (mainly the routers) do not support it. Ask you ISP, if you dont believe me. And next time think first.
Forget RMI/CORBA/DCOM etc. - this is not done for this scenario. MS even has it's own framework (DirectPlay) for handling network code in games. THe main problem is you DO NOT NEVER EVER want to use TCP :-) It can get sruck, which is a pain in the ass for anything time conservative. No way.
You ahve to use something that is UDP based, and your own layer on top of this.
Regards
Well, then I suggest you start eating your own food. Write a program that opens 40.000 Threads, and you will see what a memory and resource hog you have. A therad is pretty heavy - it needs at least it's own stack. Just at 64k per stack, 40.000 therads run you down to a memory use of 2500 Megabyte. Thats around 2.5 Gigabyte of RAM just for nothing. And the scheduler needs to check them once in a while. Try it out - and come back whining.