Game Network Engine

[cairnswm]

When I did the networking for Run-A-War last year I first tried to do it with the Indy components (UDP if IRC) - however the Indy components used all the processing power on the PC monitoring the Ports that my game didn;t work.

Thanks to Technomage I got the networking working with SDL_Net.

I would love to see something like this getting off the ground but I agree with WILL it should be free for use in the same way SDL is available to everyone.

Where possible I'd like to help.

[Sly]

Take a look at enet. It is written in C, so it would be fairly easy to port or just compile as a DLL.

[technomage]

That looks like a nice little library there Sly. I think a reliable UDP protocol is the way to go. If we did use Indy we would have to build this ontop of the current systems.

I think it might help if I gave a little background for my motivation for this prioject. I am working on a system that will require 1000-2000 connections to a server, so what ever libray is used it the server system will need to be able to handle that. I think Indy can accomodate this, I'm not sure SDL_Net can. But this is one of my requirements.

my second is that it needs to be very stable, AFAIK Indy is very stable, it has been around for years and I have very rarely found a problem in the underlying classes.

aidave - I would be interested in more details comments on the problems you had with Indy in AIR.

cairnswm - also you experiences would be usefull.

WILL- Is there any problem with having the discussion for this project here on PGD? Perhaps a section in the Game Libraries and components.

[{MSX}]

I just want to say that there is this great library:
http://www.ararat.cz/synapse/
It's very complete and easy to use. It's portable and it's all pascal. Delphi, FPC and other systems supported.
Also, i've used SDL_Net and it's very very easy to use. I suggest it if you want something up and running in short time.

bye

[WILL]

Not at all Dean. It has been too quiet in the Networking forum anyhow. That it's being used it great to see!

If this project becomes something new then ok, sure create a new thread in it's name, but no rush for that.

[WILL]

Not at all Dean. It has been too quiet in the Networking forum anyhow. That it's being used it great to see!

If this project becomes something new then ok, sure create a new thread in it's name, but no rush for that.

Hmm... perhaps a quick rundown of what the difference between TCP and UDP ports are would help those not initiated.

[technomage]

TCP - This is a network protocol that ensures that if you send your data it will get there. Using this protocol is like having a phone conversation. You are connected directly to the remote site and data is send back a forth between the two. Because it is reliable, TCP is considered to be slower than UDP, most internet protocols (HTTP, FTP etc) user TCP



UDP - This is a conectionless network protocol. The best description I have found is UDP is like putting a letter in the post, it has an address and you send it, but you have no idea if it will get there. On LAN's UDP is quite reliable, over the internet it's not as reliable as TCP. However allot of games use UDP because it is faster and has a lower overhead than TCP.

[aidave]

Indy is blocking, which means unless you use it in threads, it is going to slow down your game. It is made by alot of networking experts, who know what they are doing, so why reinvent the wheel?

There are some issues with Indy that I found to be really annoying. One was trying to find the UDP port of connecting clients (still cant figure that out). Another is disconnecting. Indy makes it seem like it supports disconnection detection but only in some cases. For the rest you have to detect yourself with timeouts etc.

If you decide to go with Indy I can teach u more.

cheers
dave

[savage]

Just to add a little more info about TCP. When TCP information is sent, it knows in what order and how much information should be received. If some information is missing ( a packet is lost during transmission ), it will re-request that bit of information again and again until it receives it. Which obviously generates more network traffic and thus can slow things down.
TCP guarantees delivery while UDP does not, so any data loss via UDP needs to be handled by the application and not the protocol.

I hope I have not muddied the waters.

[technomage]

Indy is blocking, which means unless you use it in threads, it is going to slow down your game. It is made by alot of networking experts, who know what they are doing, so why reinvent the wheel?

Quite true, this is my main reason for going with Indy

There are some issues with Indy that I found to be really annoying. One was trying to find the UDP port of connecting clients (still cant figure that out). Another is disconnecting. Indy makes it seem like it supports disconnection detection but only in some cases. For the rest you have to detect yourself with timeouts etc.

UDP is connection less so there is no way of knowin g when a UDP client is no longer sending data. Only with TCP can you detect droped connections etc.

Getting the remote UDP port is trickly in most netowrk libraries (I know it's a pain in SDL_Net) I always got round this by sending on a known port but firewalls don't always make that easy, or send the port to send info back on to the server in the first "handshake" mesages.

Some thing else I do is to use TCP to connect to the server and login, then use UDP for all the time critical information. Taht way if the TCP connections drops you can handle that and remove that client from the UDP client list as well.

If you decide to go with Indy I can teach u more.
dave

That would be cool.