We are moving towards having more and more managed programming languages. A lot of software companies are praising these types of languages through the roof, while there is a great downside of simplifying computer languages. By simplifying and making programming languages managed, I would say they are moving towards becoming an over-managed computer language.

Computer languages like C and C++ are native or unmanaged programming languages. They gets compiled to native assembly code and you need to take care of the memory handling yourself. However, managed code like Java or C# are languages where you do not need to write any extra code for memory handling. Of course this is great because we do not have to remember calling delete on our objects all the time. However, there is huge downside. If a person decides to learn for example C# by himself, he often does not need to know anything about memory handling in order to write code. However, this could have a dramatic affect on the code written, since the developer has no clue what a garbage collector is or how it allocates memory. Of course this does not mean much if he makes a simple form-application, however, making for example a multiplayer game, this could have a large affect on the scalabillity of the system. 

What is making me upset is the amount of effort into making more and more people use the managed languages. Like I said, it is great if you just need a small program for example a form, but in a larger system which may need to be fairly responsive or cant tolerate downtime, it may not be the way to go. I am not saying it is impossible to make a responsive system with no downtime in a managed language, however, it could be easier in unmanaged code. It frightens me when people are starting to drag PHP and JavaScript into this picture. I have seen several people trying to write a game-server in PHP while not really getting anywhere since the language does not yet (as I write this) support threads natively. It might be possible to install through some plugins, however the effort required to make this work is far too much when it should be considered as a part of the standard-package. And last of all, PHP is my eyes simply slow. Even though it contains a huge library for doing a lot of fancy stuff, I do not really care when the PHP process is consuming too much resources to hand out a page to some thousand users. This is since the PHP engine has to compile the website at each load causing a huge overhead related to both disk I/O and compilation time. It is of course possible to configurate caches and stuff like that, however this does not come defaultly. And last of all, PHP is meant for websites. Even Wikipedia says so: "PHP is an open source server-side scripting language designed for Web development to produce dynamic Web pages.". And yet, I do not quite understand why people want to use this language anywhere outside web-servers when PHP sites are out of the box poorly scaleable. 

I also do not get why people want to use JavaScript. One good example is the Node.js which there is a lot of discussion about. Yet, the code might look fancy, the performance could perhaps be far better if for example written in C++ specialized for the target platform.

So what does all this mean? In my opinion, it is the main reason where there are so incredibly many shitty programs who are slow or does not work properly. One example is Minecraft, an incredibly popular game written in Java. Yes, Java. The game requires a high-end computer with a dedicated graphics card to get at least 60 fps. In my eyes, this is complete madness when the graphics in the game is pixelated cubes. Yet, there are lot of these cubes in chunks which might be heavy. However, the code is poorly optimized and could have been far better if another framework which perhaps is made for games is used. Java might be good server-side, but client-side games is something game-developers should keep a good distance from. 

This does not only apply to Minecraft. Also, a lot of applications. It is often I see a lot of delay that could have easily been avoided, or buggy/sluggish apps. Large parts of the xbox moves away from the fundamentals in asynchronous programming where the UI is suposed to be responsive while an operation is being done, but I have to wait for my friend list to appear in order to close it. Spotify on the Windows Phone platform was one of the main reasons that caused me to switch over to the iOS platform as discussed in a previous post. My point is, we are seeing more and more (unexperienced) developers starting to use managed languages which often causes slow/buggy applications. This is something I think we will see a lot more of in the near future.

Many unexperienced server coders believes the socket decides a large part of the server application performance behavior. On one side they are right, however, it is the overall performance which counts. Yet the socket is a part which many does not get how to use right and then "kills" the performance of the server applications. 

Blocking vs. non-blocking

The largest and most critical point when it comes to socket is determined if you chose blocking or non-blocking sockets. (Often referred to as non-async and async) A blocking send function means that the send function will have to wait for the data it sends to be sent before it is done calling the method. When it is a non-blocking, it means the send function is queued to the .NET thread pool, and when the data has been sent, it calls a callback method. A good example is a server application which is designed to hold tens of thousands of connections and respond to requests. If we had to use blocking methods, we would have to create one thread per individual connection which later on would not make the server application really scaleable. On the other hand, if we used non-blocking methods, no extra threads would have to be created since the .NET thread pool takes care of that for us. In addition to this, we would not have to wait for data to be received on each individual thread since callback objects takes care of that. 

Exception handling

Exception throwing and catching is expensive. When a connection is closed, it throws an exception if you are using the wrong methods or if you don't check if it is connected. One example on a connection that could throw an exception if it is closed:

private void StartSend(byte[] data, int dataLength)
{
	try
	{
		socket.BeginSend(data, 0, dataLength, 0, sendCallback, null);
	}
	catch 
	{
		Disconnect();
	}
}

There is no check if the connection is connected or if it is unable to send anything. In addition, it would throw an exception if the sending did not succeed. However, it can be avoided by using the following code:

private void StartSend(byte[] data, int dataLength)
{
	try
	{
		if (socket != null && socket.Connected)
		{
			SocketError error;
			socket.BeginSend(data, 0, dataLength, 0, out error, sendCallback, null);
		if (error != SocketError.Success && error != SocketError.IOPending)
			Disconnect();
	}
	else
	{
		Disconnect();
	}
}
catch 
{
	Disconnect();
}
}

This code checks if the connection is open and if the send method managed to send the data. If it failed, it tries to disconnect without throwing any exceptions.

Closing

Closing the connection is very important if we do not want our server to have tons of non-used connections which later on would time out. Closing the socket is fairly simple:

socket.Shutdown(SocketShutdown.Both);
socket.Dispose();

The shutdown method disables any send/receive on the socket. The Dispose is technically the same as Close, since the Close method simply casts the socket to an IDisposable and then call the Dispose method. By calling the Disposed function directly, we do not have to cast the socket in the Close method.

Memory allocation

The buffer created for receiving data can be a headache for those who does not know what happens under the hood in the socket. In fact, when calling BeginSend, there is created objects which allocates far more data than a data buffer with length = 1024. (System.Threading.Overlapped, Socket.OverlappedCache just to mention a few) However, you can avoid the allocation of the buffer by creating buffer-pools for it. 

Going further

Out from my own experience with the socket class, I have to make changes to the socket class itself in order to achieve better performance. Moving the code to C++ might be a good idea since I get far more power over the memory used by the server. The overhead caused by P/invoke would not be much higher compared to the current overhead since the current socket already calls native functions by using WinSock methods.