@MasterM: Based on my testing of the server code in a dedicated scenario there is never any way to know that a client is gone so the connection pool just fills up and they are never cleared. This would never be noticed in a scenario where DOSBox is launched for everyone including the server however.

Thanks on the website. I'm really hoping a community will grow up around it. So many of these games were just too fun to allow them to slip away into nothingness. Now that I have a dedicated server working I'm going to work on getting the site up to snuff to start allowing everyone to really use it. I'm going to make it so dedicated servers can register them selves on the website so players can use them. I have a lot of things planned for the site so keep checking back periodically.

DosFreak wrote:

You may want to warn the user to use the same version of DOSBox for server/client
You may want to warn the user to use the same version of the game for server/client.

I added the warnings to the website.

I looked over the code in ixpserver.cpp in the DOSBox trunk again and it looks like it originally used a TCP socket along with a UDP socket and was changed at some point to not do this. There is a function called "closeSocket" which is no longer used which closed the TCP socket and flagged the UDP connection as disconnected. The work around I put in place essentially does what DOSBox was doing at some point. I was doing whatever I could to not have to modify the DOSBox code.

I'm curious if DOSBox could be modified to send a UDP packet that signals the server to clear the connection pool reference whenever "ipxnet disconnect" is executed. It would probably have to spoof an IPX packet to work correctly, but I'm not 100% sure on that. If this could be done I could get rid of the TCP server code I wrote and the disconnect logic would be more reliable. I think right now since I'm having to sync the connections using a host name this could be problematic for multiple clients coming from behind a NATed firewall, but I need to test it to make sure.

I have created a patch that makes MasterM's ipxnet reuse connection slots, once the host associated with it has not sent any data for a while.

The CONNTIMEOUT is set to 15 minutes (900 seconds).
Also this patch increases the maximum number of connections from 16 to 32 and removes the reconnect ability, since my dosbox client doesn't use it anyway.

svn diff:

1Index: ipxserver.cpp
2===================================================================
3--- ipxserver.cpp       (Revision 3)
4+++ ipxserver.cpp       (Arbeitskopie)
5@@ -71,8 +71,15 @@
6 
7   srcport = tmpHeader->src.addr.byIP.port;
8   destport = tmpHeader->dest.addr.byIP.port;
9-       
10 
11+  // update activity timer for sending host    
12+  for(i=0;i<SOCKETTABLESIZE;i++) {
13+    if(connBuffer[i].connected && (ipconn[i].host == srchost) && (ipconn[i].port==srcport)) {
14+      connBuffer[i].lastused = time(NULL);
15+    }
16+  }
17+
18+
19   if(desthost == 0xffffffff) {
20     // Broadcast
21     for(i=0;i<SOCKETTABLESIZE;i++) {
22@@ -160,28 +167,22 @@
23       if(tmpHeader->dest.addr.byIP.host == 0x0) {
24        UnpackIP(tmpHeader->src.addr.byIP, &tmpAddr);
25        for(i=0;i<SOCKETTABLESIZE;i++) {
26-         if(!connBuffer[i].connected) {
27+          // use an empty connection slot or reuse a connection slot, if the host has not sent anything for CONNTIMEOUT seconds
28+         if((!connBuffer[i].connected) || ((time(NULL) - CONNTIMEOUT) > connBuffer[i].lastused)){
29            // Use prefered host IP rather than the reported source IP
30            // It may be better to use the reported source
31            ipconn[i] = inPacket.address;
32 
33            connBuffer[i].connected = true;
34+           connBuffer[i].lastused = time(NULL);
35            host = ipconn[i].host;
36            LOG_MSG("IPXSERVER: Connect from %d.%d.%d.%d", CONVIP(host));
37            ackClient(inPacket.address);
38            return;
39-         } else {
40-           if((ipconn[i].host == tmpAddr.host) && (ipconn[i].port == tmpAddr.port)) {
41-
42-             LOG_MSG("IPXSERVER: Reconnect from %d.%d.%d.%d", CONVIP(tmpAddr.host));
43-             // Update anonymous port number if changed
44-             ipconn[i].port = inPacket.address.port;
45-             ackClient(inPacket.address);
46-             return;
47-           }
48-         }
49-                                       
50+         } 
51        }
52+       LOG_MSG("IPXSERVER: Connection Table full.");                   
53+       return;
54       }
55     }
56 
57Index: ipxserver.h
58===================================================================
59--- ipxserver.h (Revision 3)
60+++ ipxserver.h (Arbeitskopie)

61@@ -21,6 +21,7 @@
62 #define DOSBOX_IPXSERVER_H_
63 
64 #include <SDL/SDL_net.h>
65+#include <time.h>
66 
67 struct packetBuffer {
68   Bit8u buffer[1024];
69@@ -29,9 +30,11 @@
70   bool inPacket;      // In packet reception flag
71   bool connected;              // Connected flag
72   bool waitsize;
73+  time_t lastused;     // last time the host sent something
74 };
75 
76-#define SOCKETTABLESIZE 16
77+#define CONNTIMEOUT 900 
78+#define SOCKETTABLESIZE 32
79 #define CONVIP(hostvar) hostvar & 0xff, (hostvar >> 8) & 0xff, (hostvar >> 16) & 0xff, (hostvar >> 24) & 0xff
80 #define CONVIPX(hostvar) hostvar[0], hostvar[1], hostvar[2], hostvar[3], hostvar[4], hostvar[5]

Update:

I now have a Windows based server up and running. If you want to test it out go to http://www.classicgamingarena.com and set your host as server1.classicgamingarena.com and port 6000. Make sure to check the dedicated check box. Also you will need to get the latest version of the CGA client as well. It will connect to the server using TCP to maintain connection state.

I haven't messed with the max number of connections yet so it is still 16. A good test if anyone is willing and/or able would be to connect to the server from 2 different computers behind a NATed firewall. I'd like to see how the connection information comes in during that scenario.

Let me know what happens...so far tests locally have been great. I even played my wife in DOOM with her on a laptop connected wirelessly to the server.

Thanks guys. 😀

...and it's down again.

temptingthelure wrote:

...and it's down again.

Sorry, it's up now. Went out of town this weekend and there were thunderstorms in Memphis. Needless to say the power jumped a few times and the server rebooted.

EDIT: I also discovered last night that the server I put together to test with has a wonky power supply in it so it may restart or shutdown randomly. I'm going to move the server software to a different server when I get home tonight.

The dedicated server is now on a different, better server and will stay up and running.

DosFreak wrote:

I meant if you want them to connect to classicgamingarena to generate a config then you could implement those features or links to those sites on that website.

I meant to reply to this a while ago.

I'm going to setup the site so that players won't have to know all the command line switches and what not for the games. They will be able to go in and setup a game room with all the proper settings and others will be able to just join the room and go. Pretty much how the clients of old worked (ie: MPlayer...the others escape me right now, but there were several clients of this sort in the late 90's)

I'm in the process of getting all of this put together now.

EDIT: The services that existed that were website based were MPlayer.com and Heat.net. Both failed, I'm thinking due to the lag issues as a result of the providers hosting all the servers and not the community. I used both these services at one time or another and I remember how laggy they were.

Just a quick update with the dedicated server port for Windows and the CGA client. I was able to resolve the disconnection issue with multiple connections coming from behind a NATed firewall. I also updated the server logic to allow setting the maximum number of connections instead of it being hard coded at 16. The code I wrote to correct the NATed clients issue will also prevent someone from connecting directly to the UDP port and taking up your connections (either maliciously or accidentally). I also took some steps to hide the UDP port from the end user to help prevent someone from trying this.

The latest version of the client will be needed before using the test server, but everything seems to be working very well now. I was on vacation last week in Florida and I tested from there. I had 2 laptops using wireless through a LinkSys Wireless firewall/wap connected to the server back in Memphis trough a DSL connection and you couldn't even tell you were playing over the internet. All clients disconnected perfectly.

Checkout http://www.classicgamingarena.com for updates.

Just to let everyone know I'm working on porting my code to Linux. What I ended up doing was taking the server code that MasterM put together and created a stand-alone library....actually quite a while ago. I wrote the server in Delphi creating both a straight console application and service that uses the library (ipxnet.dll).

I used Visual C++ under windows to create the library (I loath VS), but over the weekend I ported the C code to Pascal using Free Pascal since it has the necessary SDL and SDL_Net headers and is cross platform. The new library is working perfectly and I am going to work on compiling the new library as well as the console server to Linux tonight. If everything goes well I will be porting the client also.

I got the server built under Linux last night and so far it working perfectly.

[OK, I already posted this as a separate thread, not familiar with this BB UI]

Hi all,

Not having seen this thread, I stayed up late last night and whipped out a dedicated IPX server on my own. I quickly determined that using SDL_net would not perform well, since SDL_net doesn't have support for blocking UDP receive.

A significant criterion was that an idle server should burn resources, so this server is designed so that when completely idle it will not consume any CPU time at all.

It is tested on Linux; it should compile on any modern Unix system (including Mac) without modifications. It may be possible to build it under Cygwin on Windows, or it should be relatively straightforward to port it to native Windows (the biggest difference is probably the client expiration timer, which is technically optional.)

ftp://ftp.zytor.com/pub/games/dosbox/ipxrelay-0.1.tar.gz
http://git.zytor.com/?p=games/dosbox/ipxrelay.git;a=summary

Obviously that should have been: an idle server should not burn any CPU resources...

I have just uploaded a new version with Windows support as well (untested, but it compiles under MinGW32).

The .zip file contains source as well as a Windows binary.

ftp://ftp.zytor.com/pub/games/dosbox/ipxrelay-0.2.tar.gz
ftp://ftp.zytor.com/pub/games/dosbox/ipxrelay-0.2.zip

hpa wrote:

I have just uploaded a new version with Windows support as well (untested, but it compiles under MinGW32).

The .zip file contains source as well as a Windows binary.

Hi there.

So brilliant to see someone coding another ipx relay for Dosbox.

I have compiled your source to run it on Linux Debian.

I am currently running it on port 10000 for testing it.

yangserver.com 10000

Nice job.

So far so good I tried "Magic Carpet 2" using netbios with it, "Rise of the Triad", "Blood", "Duke Nukem 3D" "Descent 2" and "Dungeon Keeper".

All connected fine except the game "Dungeon Keeper."

For some reason I could not see the LAN session & no room appeared like it normally would.

Maybe a bug somewhere.