mDevelopmentLog[4] = More Networking

Hello Turtles,

So last week Monky bird and Sara cat commanded me to fiddle with adding a networking layer to TurtleBrains and thus was to be continued for a second week, to ensure that the networking layer could be used on Windows as well as Mac and Linux. Long ago I remember a teacher or someone experienced talk about how the sockets in WinSock are straight-forward and based on sockets used in unix systems. For the most part that is true, but, not the complete story.

The Windows socket API tends to return SOCKET_ERROR during a failure and then a call to WSAGetLastError() for more information. That is similar to the unix style, which returns -1 on error and errno / strerror(errno) for more information. That strerror trick is amazing. If one assumes that SOCKET_ERROR is, and will always be, defined as -1, then the same code could theoretically work on both. I did dig through the headers and that is theoretically a safe assumption, however, I didn’t assume it will always be that way.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
//Example of handling an error Windows vs Mac/Linux.
const int selectReturn = select(0, &set, 0, 0, &timeoutValue);
 
#if defined(tb_windows)
if (SOCKET_ERROR == selectReturn)
{
    const int errorCode = WSAGetLastError();
    tbi_log_error("tbNetwork Error: Select error: %d\n", errorCode);
    return false;
}
#elif defined(tb_macosx) || defined(tb_linux)
if (-1 == selectReturn)
{
    const int errorCode = errno;
    tbi_log_error("tbNetwork Error: Select error: %d (%s)\n", errorCode, strerror(errno));
    return false;
}
#endif

So that is what it looks like on a basic level. Speaking of select, the return value on both apis is to be non-zero if one of the sockets within set have incoming data to be handled. I was unable to figure out why, no obvious errors, but TCP sockets on Mac/Linux were never collecting incoming data, select always returned 0.

It was actually quite difficult to stay motivated and focused on the networking layer of TurtleBrains. Partially because during the previous week I realized the API was going to be remaining unstable for quite some time. The test case I had setup was not “real-world” enough to be comfortable defining a stable/usable interface. So while it works on a basic level, it probably isn’t done well enough for real use. I knew some people wanted to try the networking and that did actually help my motivation to get it working on Mac/Linux. Unfortunately only TCP is still not working, though the rest is, on that basic level.

Moku also gave me the final art for the EggDrop Tutorial for TurtleBrains, and it looks great. I went to export the source art into png files to drop into the game and found that InkScape didn’t load the svg files properly, missing paths/objects and such. Potentially some options Moku has in saving, but not quite sure, maybe next week.

Until then, have a good one!

Comments are closed.