I would like to know which of WCF or .NET Sockets is the more efficient and the more recommended in a game developpment scenario.
Here are the different parts of the game :
-a client/server communication to play on the internet
-peer to peer on local network.
I would like to know which technology you would use on these parts (wcf on both, socket on both, wcf on one and socket on the other...) and why, if possible.
The game involved doesn't require a high communication frequency (3-4 per second is enough).
WebSockets typically run from browsers connecting to Application Server over a protocol similar to HTTP that runs over TCP/IP. So they are primarily for Web Applications that require a permanent connection to its server. On the other hand, plain sockets are more powerful and generic.
Socket programming is a way of connecting two nodes on a network to communicate with each other. Basically, it is a one-way Client and Server setup where a Client connects, sends messages to the server and the server shows them using socket connection.
A socket is the end point of a bi-directional communication between two processes running over a network. You can leverage the System.Net and System. Net. Sockets namespaces to work with sockets in C#.
In fact, WebSockets is built on normal TCP sockets and uses frame headers that contains the size of each frame and indicate which frames are part of a message. The WebSocket API re-assembles the TCP chunks of data into frames which are assembled into messages before invoking the message event handler once per message.
The purpose of WCF is to save developers writing code for different transport protocols and it has large number of features so thats why it is slower than Sockets. Plus WCF is for service oriented applications. I dont think Games fall into this category.
But as you mention only 3-4 requests per second, WCF might be a better option as its very flexible and will save a lot of development time.
Some points:
The bindings that start with net* are meant to be used between .NET applications. (Both client and server WCF)
If any of the one is not WCF: You can only use the bindings that does not start with a net prefix. BasicHttpBinding, WSHttpBinding etc. These are much slower than the net* bindings as lot of overhead is there.
You can go ahead with NetPeerTcpBinding and play with it for a while. It also supports duplex communication.
Here are some useful links for P2P:
Peer-to-Peer Programming with WCF and .NET Framework 3.5
http://blogs.interknowlogy.com/2009/08/05/building-a-really-simple-wcf-p2p-application
Both technology can manage the number of requests per second that you are mentionning, however the programming model is quite different. Sockets are very low level and require that you build your own communication protocol on top of it. However, the overhead can be minimal. WCF is modelled after RPC (Remote Procedure Calls) and provides an abstraction on the transport. It allows you to use the same API with very different technologies such as web services or messaging. However, the abstraction provided has its own set of problems such as a certain complexity or steep learning curve...
In your case, you could also look at messaging technologies such as MSMQ, ZeroMQ or ActiveMQ that provide a nice abstraction over sockets and simplify the development a lot.
If you want to maximize performance sockets is the way to go, WCF has both data and processing overhead. But... if performance is that critical to you, you should also consider assembler instead of c#.
WCF will handle 3-4 requests per second without a blink.
I would start with WCF, it will save you a lot of development time, no need to roll your own parser etc. You can concentrate on other parts on the game instead. If it actually turns our that WCF is too slow for your game you can throw WCF out and go for sockets instead.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With