Telnet : A code snippet that embeds a telnet client or server into your application

This might well be the single most useful code snippet I have ever published. I took some old code that was originally written as part of Novodex Rocket, later to become PhysX Rocket, and re-packaged it into snippet form. This code was largely written by my friend James Dolan, though some of it is mine as well. Back when I was at Ageia we open-sourced the Rocket application and this code was part of that release.

The only thing keeping this snippet from being widely useful is that, currently, it only builds on Windows or XBOX machines. I have not yet ported it to Linux, Apple, Iphone, etc. It would be extremely useful on those platforms. If anyone wants to volunteer to revise the code so that it conditionally compiles for those targets I would greatly appreciate it!

What this code snippet does is that it allows you to embed a telnet server, or client, into any application. Simply include the source into your project (telnet.cpp and telnet.h).

Somewhere on startup in your code call:

TELNET::createTelnet("localhost",23)

This will create an instance of the telnet client/server system. The first time you start it up on your machine, it should find port 23 free, and it will be created as a server. The second time you launch it, it will see that port 23 is used, and instead it will launch as a client. You can launch as many clients as you want and, of course, they don't have to be on the same machines.

You can also just use an ordinary telnet client of any flavor and connect to your application.

So, what is this good for? It allows you to send debug commands and receive log spew from any application, without having to write any GUI interfaces. This is especially useful for console games or anything running on an embedded system. Think of it as a 'back door' way to poke commands into a running application and receive debug spew back out again.

You can also use it as a quick and dirty way to do network communication.

The code itself could be a little cleaner but, hey, it works. I took what was previously about a dozen source files and combined them into one single large CPP file of roughly 2,000 lines in length.

However, that is all about implementation and what you care about is the interface.

Below is the entire header file for the telnet system.


namespace TELNET
{

class Telnet
{
public:
virtual bool isServer(void) = 0; // returns true if we are a server or a client. First one created on a machine is a server, additional copies are clients.

virtual bool haveConnection(void) = 0; // returns true if we (as a client) successfully connected to the server.

virtual bool sendMessage(unsigned int client,const char *fmt,...) = 0; // send a message to the server, all clients (client=0) or just a specific client.

virtual const char * receiveMessage(unsigned int &client) = 0; // receive an incoming message (client=0) means it came from the server, otherwise it designates a specific client.

virtual const char ** getArgs(const char *input,int &argc) = 0; // parse string into a series of arguments.

protected:
virtual ~Telnet(void) { };
};

Telnet * createTelnet(const char *address="LOCALHOST",unsigned int port=23);

void releaseTelnet(Telnet *t);

};

extern TELNET::Telnet *gTelnet; // optional global variable representing the TELNET singleton for the application.



You can download the source directly from this location:

telnet.h
telnet.cpp

Or, I recommend you sync to the Google code repository as it is guaranteed to always be the most current.

More commentary about multiplatform development for mobile devices; including Iphone

I received the following emails from developer Benjamin Lee who confirmed that my strategy of doing multiplatform development by using Visual Studio on the PC was a good approach.

John,

I stumbled across your blog. Kudos for you for doing your dev on the PC. We actually do the same here. Our SDK runs on PC, Mac, and the iPhone. It runs nearly identical on all platforms, using the same datasets too. Aside from the obvious input differences, the only other differences we occasionally find are render issues, since the PC may render scenes slightly differently.

If your stuff already works well with the iPhone, then being able to have pretty stable Mac running code would be no problem. We could probably do the same with the Mac, but I have one mactoppie and the screen size is way too small to get any effective work done.

Thanks posting an interesting blog.

Ben

and a follow up:

John,


And as you mentioned in your comment to anon on your "iphone development framework" post ... since you wanting to support more platforms, your method is really the way to go. To do otherwise is the long way around.

We developed the PC SDK first. Then ported to Mac. Then ported to iPhone. The iPhone port took less than a day. We will probably port to the Wii next. But I expect that port to be very quick.

You could also cite that other advantages are that you can do much better memory leak testing on the PC. While Instruments can be used (and we do test up against it), the PC provides a much better environment for memory counting (at least for us since like you, we were not Mac or iPhone people).

Ben