Not the face to face type but actual networking. This is needed because I’m working on a game server. My mobile game (Manana Banana) will become networked enabled and thus multiplayer.  C# is ideal for this type of thing but I’m not using the networking capability of MonoGame instead managing the whole lot myself.

Back a few years ago when I was a full-time mobile developer I wrote an app that was used by taxi drivers. It was a conversion of an Android App (I wrote it from scratch running on an iPhone based on the Android source code).  There’s a curious architecture with such apps because not only is the a user interface but in the background the app was “chatting” over 3G to a central server (written in VB6 I kid you not) which sent an “are you alive?” message every six seconds to every driver’s phone.

It was not a traditional client-server architecture but the kind of system where the driver could send a message to the server or the server could send a message to the driver. 

What this meant was the app was always keeping one eye on the 3G, getting messages and then it might for instance popup a screen saying “There’s a job from x to y. Do you want it?”. If the driver said yes then the app would receive details and show the driver the route to the pickup point. If the driver didn’t respond within 30 seconds or said no then the program would pass that back to the server,

What is a ConcurrentQueue?

C# has an advanced data structure called a ConcurrentQueue<t> which is a thread safe generic queue. I used two of these, one for a receive queue and one for a transmit queue in conjunction with a thread that never finished. All the 3G stuff was done using C# TCP/IP clients and ran in this thread. Messages that came in were put on the receive queue and could be popped off and processed in the main program. Messages to send out from the main program were put on the transmit queue and sent out in the thread. It was a very clean way of separating the main application running in the main thread from the 3G running in a background thread. 

Compared to the Android program which was all running in one thread and polled the 3G, I was told by my drivers that my app felt much more responsive!   The screenshot above was a very early image of it. It had a very simple UI where each screen of controls (Views in iOS parlance) was built up dynamically.  

Also C#/Xamarin has a way of getting from a thread to the main thread on iOS. You cannot update any controls from any thread only from the main UI thread.  There’s a method called InvokeOnMainThread for the Xamarin iOS controls. See this Microsoft/Xamarin documentation on how to use it. So that’s what I’ll be doing in my networked game.  

Interestingly because I’m managing everything, the TCP/IP messages can be very small, under 20 bytes each. This allows a very high throughput.