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.
