r3dux.org

Back in January this year I was due to be teaching some diploma level programming (roughly equivalent to the UK A/S level for any Brits), and part of that had to deal with network programming with sockets and stuff, so I duly did my research and put together a simple chat server and client in SDL_net. And then my classes changed and I got moved on to teach other stuff. I wasn’t too upset though – I’d learnt a lot, and I’d put up the code to help people out who might be in a similar situation, so it was all good.

But now in November I’m back on programming duty, so I dug up my code, looked it over, and thought Naah – I can’t use that, it’s unweildy, and complex, and it would be a real pain to try to re-use the code. So I’ve gone back to the drawing board and refactored it all into something I hope is a lot more palletable and both easy to use and re-purpose. In effect, I’ve refactored it into two wrappers which now consist of a ServerSocket class and a ClientSocket class.

Check it out…

Cross platform socket connectivity? That'll be a yes, then...

Socket Server

The old chat server was 250 lines, it’s now down to 77:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77

// Re-written simple SDL_net socket server example | Nov 2011 | r3dux
// Library dependencies: libSDL, libSDL_net
 
#include <iostream>
#include <string>
#include <SDL/SDL_net.h>
#include "ServerSocket.h"
 
int main(int argc, char *argv[])
{
	// Initialise SDL_net
	if (SDLNet_Init() == -1)
	{
		std::cerr << "Failed to intialise SDL_net: " << SDLNet_GetError() << std::endl;
		exit(-1);
	}
 
	// Create a pointer to a ServerSocket object
	ServerSocket *ss;
 
	try
	{
		// Try to instantiate the server socket
		// Parameters: port number, buffer size (i.e. max message size), max sockets
		ss = new ServerSocket(1234, 512, 3);
	}
	catch (SocketException e)
	{
		std::cerr << "Something went wrong creating a SocketServer object." << std::endl;
		std::cerr << "Error is: " << e.what()   << std::endl;
		std::cerr << "Terminating application." << std::endl;
		exit(-1);
	}
 
	try
	{
		// Specify which client is active, -1 means "no client is active"
		int activeClient = -1;
 
		// Main loop...
		do
		{
			// Check for any incoming connections to the server socket
			ss->checkForConnections();
 
			// At least once, but as many times as necessary to process all active clients...
			do
			{
				// ...get the client number of any clients with unprocessed activity (returns -1 if none)
				activeClient = ss->checkForActivity();
 
				// If there's a client with unprocessed activity...
				if (activeClient != -1)
				{
					// ...then process that client!
					ss->dealWithActivity(activeClient);
				}
 
			// When there are no more clients with activity to process, continue...
			} while (activeClient != -1);
 
		// ...until we've been asked to shut down.
		} while (ss->getShutdownStatus() == false);
 
	}
	catch (SocketException e)
	{
		cerr << "Caught an exception in the main loop..." << endl;
		cerr << e.what() << endl;
		cerr << "Terminating application." << endl;
	}
 
	// Shutdown SDLNet - our ServerSocket will clean up after itself on destruction
	SDLNet_Quit();
 
	return 0;
}

Socket Client

And the old chat client was 313 lines, which is now down to 83:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83

// Re-written simple SDL_net socket client example | Nov 2011 | r3dux
// Library dependencies: libSDL, libSDL_net
 
#include <iostream>
#include <string>
#include <SDL/SDL_net.h>
 
#include "ClientSocket.h"
 
int main(int argc, char *argv[])
{
	// Initialise SDL_net (Note: We don't initialise or use normal SDL at all - only the SDL_net library!)
	if (SDLNet_Init() == -1)
	{
		std::cerr << "Failed to intialise SDL_net: " << SDLNet_GetError() << std::endl;
		exit(-1);
	}
 
	// Create a pointer to a ServerSocket object
	ClientSocket *cs;
 
	try
	{
		// Try to instantiate the client socket
		// Parameters: server address, port number, buffer size (i.e. max message size)
		// Note: You can provide the serverURL as a dot-quad ("1.2.3.4") or a hostname ("server.foo.com")
		cs = new ClientSocket("127.0.0.1", 1234, 512);
	}
	catch (SocketException e)
	{
		std::cerr << "Something went wrong creating a ClientSocket object." << std::endl;
		std::cerr << "Error is: " << e.what()   << std::endl;
		std::cerr << "Terminating application." << std::endl;
		exit(-1);
	}
 
	try
	{
		// Attempt to connect to the server at the provided address and port
		cs->connectToServer();
 
		string receivedMessage = "";
 
		cout << "Use /quit to disconnect or /shutdown to shutdown the server." << endl;
 
		// Display the initial prompt
		cs->displayPrompt();
 
		// Run the main loop...
		do
		{
			// Check if we've received a message
			receivedMessage = cs->checkForIncomingMessages();
 
			// If so then...
			if (receivedMessage != "")
			{
				// Display the message and then blank it...
				cs->displayMessage(receivedMessage);
 
				// ...and then re-display the prompt along with any typed-but-not-yet-sent input
				cs->displayPrompt();
			}
 
			// Get and deal with input from the user in a non-blocking manner
			cs->getUserInput();
 
		// ... until we decide to quit or the server is shut down
		} while ( (cs->getShutdownStatus() == false));
 
	}
	catch (SocketException e)
	{
		cerr << "Caught an exception in the main loop..." << endl;
		cerr << e.what() << endl;
		cerr << "Terminating application." << endl;
	}
 
	// Shutdown SDLNet - our ClientSocket will clean up after itself on destruction
	SDLNet_Quit();
 
	return 0;
}

On top of all this we have try/catch exception handling, a nice encapsulated & easy to work-with/modify/extend design and debug flags to control whether the client/server should be verbose or run silently. Obviously the chat client itself can’t run completely silently – you wouldn’t be able to read the messages being sent back and forth! – but when debug is off it only ever outputs anything when it receives a message or when the user enters messages to send, so it’s pretty darn quiet.

Oh, and it now comes in Linux and Windows flavours =D

Overall I’m really happy with it – it’s taken a few days to properly redesign and test (not to mention the issues involved with porting to Windows) – but I think the next time I need to do some socket stuff with C++ I’d be able to grab this code, make whatever modifications I need and get something up and running in no time.

Awthome! =P

Download links

• Linux Client and Server Code (Code::Blocks projects, libs not included)
• Windows Client and Server Code (Visual Studio 2008 projects, libs included)

Notes on Building for Windows

The windows client and server projects have some important tweaks made for them to compile, and it’s worth mentioning what they are:

• The solution (which contains two projects) comes comes with a copy of the SDL and SDL_net libs and headers all merged together in the SDL folder (well, there are separate libs and include folders, but all the headers from both are in the include folder and all the libs from both are in the libs folder).
• Each project has the following libraries linked in: SDL.lib, SDLmain.lib and SDL_net.lib, these libraries point to…
• SDL.dll and SDL_net.dll which are in the solution’s Debug folder, so you can compile and build from Visual Studio, BUT you’lll need to copy these two dll files into the same folder as the SocketServer-Rewritten.exe or SocketClient-Rewritten.exe folders to run the executables “standalone” in other locations as opposed to build-and-run-from-visual-studio style!
• The projects are defined as console applications, and because SDLmain.lib defines the main function as int main(int argc, char *argv[]) and not just int main() you MUST keep the definition of main in-line with the SDLmain.lib definition.
• Finally, the projects will only build successfully in debug mode. Why? I’ve no idea. If you know how to fix it then go for it!

Update: The method below for getting a virtualbox IP from your DHCP works (in linux) – but it turns out there’s an easier way (kindly pointed out by Mike in the comments below). You can just change your VirtualBox network settings from NAT to Bridged Adapter and point it at eth0/wlan0 or whichever connection is being used for networking. Then, optionally, you can configure the MAC address of the bridged adapter and set your router to assign a specific IP to a specific bridged adapter. Also, the built-in Bridged Adapter method works to deploy solutions from XNA Game Studio to my Xbox 360, so I’m rapt! Thanks, Mike!

Note: The below bit is for linux only, the above method should work on any host OS!

VirtualBox is an awesome bit of kit and I <3 it long time ten-dorrah.

But by default when your virtual copy of Windows/Linux/Solaris/Whatever grabs an IP address, it does so through NAT, and at version 3.0.4, this means it gives us a default Category A network address (i.e. 10.x.y.z).

It’s a working cat-A address, as in it’s fully functional and can talk to the Internet and all that, but sometimes life is a lot easier if you have an IP in the same range as the DHCP pool your router is dishing out. For example, my lappy is 192.168.1.101 internally, my Wii might be 192.168.1.102, the NAS .103 etc, so I want my virtualboxen to take addresses like .104, .105 and such.

I’m doing this to bridge my wireless connection on wlan0, if you’re bridging an ethernet connection substitute eth0 or whatever connection as necessary.

Also, to perform the bridging using this method, you’ll need some tools (feel free to sudo apt-get install NAME-OF-TOOL as necessary):
- 1.) uml-utilities
- 2.) parprouted
- 3.) bcrelay

Now, with that lot installed, run the following commands (provided here in bash script form):

#!/bin/bash
 
# To use this script you will need the following utilities installed:
# 1.) uml-utilities 2.) parprouted  3.) bcrelay
# sudo apt-get install 'em
 
# Enable IP forwarding
sudo sysctl net.ipv4.ip_forward=1
 
# Create a TAP as your current logged in user (replace with -u YOUR-USER-NAME if you want...)
sudo tunctl -u $USER
 
# Tell tap0 to respond to ARP (Address Resolution Protocal) packets 
sudo sysctl net.ipv4.conf.tap0.proxy_arp=1
 
# Give your TAP (tap0) an IP address and enable it (make sure the IP address is OUTSIDE the DHCP range on your router)
sudo ip addr add 192.168.1.150/32 dev tap0
sudo ip link set tap0 up
 
# Run parprouted and make it add routes automatically for wlan0 and tap0 as needed
# Make the command "parprouted -d wlan0 tap0" to display routes added and additional info. No sudo necc. for this one.
parprouted wlan0 tap0
 
# Use bcrelay on your net connection and TAP to "rewrite the layer-2 header and forward broadcast messages between network interfaces"
# The "-d" in this instance MAKES bcrelay work as a daemon. Need to sudo this or it doesn't work.
sudo bcrelay -d -i tap0 -o wlan0

Now, fire up VirtualBox and for your machine of choice change the network selection from NAT to tap0 as shown:

Then boot up your virtual machine and check the IP:

Great. Super. Smashing. =D

Note: The entire reason I wanted to grab an IP from the router was so my virtual copy of XP could be on the same network as my XBox 360, so I could deploy games to it through XNA Studio 3.1, however XNA Studio is very fussy about timing when it comes to registering the 360, and although it can see the 360 using the bridge, and it tries to connect, it times out before it can fully establish a connection. I guess I’ll have to go with an IP routes method of bridging if I want it to work for that purpose, but as yet I haven’t quite figured it all out. Will keep trying when I have time, or if you know a way, feel free to call me technically incompetent and sling a solution in the comments! Cheers!