def

We break down the process of how a message is routed from the end user to your app or service.

MXit users obtain MXit from our site, m.mxit.com or from app stores such as the Apple App Store, Android Marketplace and BlackBerry App world.

Once they have successfully logged in to their account, they then have access to a shop called Tradepost which contains all sorts of services and items. Currently MXit API Apps from third parties are being listed under Tradepost's Workshop Inventions. Specialized placements throughout MXit are available through our business division.

Now, the MXit user has a TCP connection open to the MXit backend (login servers or proxies). This is naturally a duplex connection so that information can be pushed back and forth between the user and the backend in realtime.



Client protocol
There is a MXit Protocol that is spoken between the devices and the MXit backend. i.e. the way messages are packaged over the TCP connection.

Your App Servers Connection
Your App server connects to the MXit backend via the API server. The app opens a TCP connection (nettcpbinding in WCF) to the API server and receives all the messages from all the users over one pipe. Therefore the bandwidth of your connection to the API server will play a role in determining how many concurrent messages your application can ultimately handle.

Processing messages
Your App Server will also be responsible for processing as many messages as possible. Do not try to process and send the response to a message received on the same thread as on which you received the message. This is so that there are always threads in the .NET ThreadPool available to process incoming messages regardless of how long your processing and replying takes. A way to do this would be to handle the processing and responding of messages onto a queue to be processed by another threadpool you create.

When a user sends a message, it travels through the backend and reaches your app server pretty much as it was sent from the device. Above the MXit Protocol there is a Command Markup called the MXit Command Markup, which defines how specially formatted items should look, e.g. clear screen commands, clickable links etc.

There is also another section of markup called Graphics Markup which defines some client side features, e.g. moving and placing of objects, image sprite caching, accurate layouts etc. There will be another article where we explain Graphics Markup in more detail and how you can use it in your app or service.