Reason #8: Client-Server Interactions Must Be Programmed Manually in C#

20 Reasons to Migrate Magic eDeveloper, uniPaaS and Magic xpa to .NET by Upgrading Rather than Converting

Reason #8: Client-Server Interactions Must Be Programmed Manually in C#

We’re continuing our series of articles for those comparing migrating Magic applications to C#.NET or ASP.NET and the simpler alternative of upgrading Magic to Magic xpa, which is fully .NET based. Since so many Magic applications are client-server in nature, we need to consider what a client-server application loses when it is stripped of its platform.

Are you really eager to maintain a code base that is machine generated and that does something you’ve never had to do as a Magic programmer: manage low-level client-server communications? Creating a client socket in C# with ordinary .NET functions is messy, to say the least. And once you have the socket, you need to create an instance to get event-driven access to the data. Receiving data with  doesn't guarantee your messages arrive in one piece, though. So more manual programming is required.   You’ll need to program ways to keep messages together, for example you might create one suitable for simplistic text messaging and one suitable for arbitrary message-based communication.

So you’ll have to write programs that are also able to pass text with a suitable end marker, such as a new line. But what if a new line is a part of the data you want to pass? Oops, more programming. Now you’ll have to create handlers for data received in read events.

On the server side, you also need to be receiving and sending information (just like a client). But a server has to also keep track of who is connected to it. More programming. It might also be necessary to be able to broadcast messages, that is send them to every client currently connected. More programming.

You’ll also have to write (and/or maintain) code that gives you the ability to protect a socket, using encryption algorithms. More programming. You have to be able to pass an encryption type. More programming. How many encryption types might your application need to support? Oops. More programming for each one! Skip this step by just not telling your boss and you’ve taken a formerly secure Magic application and completely exposed it. Not good.

But wait we’re not done with discussing what you have to do and maintain for encryption in client-server communication layers. First, remember that the server needs to be able to send either a public or private key; because if the key is sent unencrypted, this is not very secure, but it does mean that the communication is not in plain text. The client will also need to generate a symmetric key and encrypt it before sending it to the server. More programming. This is the only way to be sure that the key is never visible to a third party and the connection is kept secure; to access the message you would need to break the encryption algorithm.

If you choose to use encryption in a Magic application, very little is different in your programs and nothing is needed to secure communication between the client and the server. However, in C# programming for your server, you’ll have to program a way for the server to know when the client is ready because the encryption protocols have succeeded. More programming. Otherwise, the client is called before key exchange is complete and the client is not ready to send and receive data. Do you really want to be responsible for maintaining all of this code?

If you attempt to send data to a client before it is ready, it should result in an exception. Similarly, if you want to send data through an encrypted client socket, you should be prepared to write code that will respond to a ready event or check an encryption ready property before even sending data. Stupid, useless (but absolutely necessary code) that the conversion generates by machine and you must maintain ad nauseum into the future.

Imagine in C#, just trying to create a basic server class - without the guts. You’ll need to write programs to create a TCP listener. (Have you got to the business logic yet? No way, not even close!) You’ll need this to wrap up the underlying socket communication, and open threads which will be listening for client connections. You’re also going to need to write functions that listen for clients and that can be used to manage the start up of threads. 

This function is going to have to start up TCP listening and then sit in a loop accepting connections. Oh joy, loop programming in C#. You’re also going to need a function to call TCP clients and these will have to be blocked until a client has connected, at which point you need more code to fire off a thread to handle communication with that new client. You’re going to have to write code that allows your thread firing mechanism to be parameterized too. Otherwise, how will you efficiently handle client communications?

I’m sorry, but I have to stop writing this article. We aren’t even one fourth of the way through discussing the kinds of programming required for client-server communications. Do you really want to be responsible for maintaining all of this? You and what programming Army? Right now, you do have a programming Army that protects you from all of this: it’s Magic!

For additional information on how an upgrade to Magic xpa is superior to Magic uniPaaS to .NET conversion please convert here.