IM

[shvarz]

Time-outs in IM are annoying on their own, but they also cause the sim to pause for a long time. Sometimes the sim stops completely, I've waited for several minutes for it to get going, but it just sits there. Shutting down the program and then restarting helps. Maybe there should be some kind of "release" from such situations, which would just drop the internet mode and get the sim going until better times?

[Peter]

If I understood some of the posts of Eric, this happens becouse VB is single threaded. Simply it can't wait and go further with the sim, the only solution I see, is to make a special IM-DB program, that communicates with the FTP-server for DB.

I haven't coded such things so I don't know exactly. But anyway, Iám not sure if this would trouble IM, but couldn't you just run two DB instances, if the one is waiting the other has full CPU-capacity. You wouldn't have one sim running at full speed , but atleast two at the half speed.

[EricL]

DB is single threaded because it is written in Visual Basic 6.0, which only allows the creation of single threaded executables.  In coming months, I may explore porting the VB code to a more modern version of VB.  A newer version would allow for the addition of additional threads of execution which would allow the program to do multipel thigns independently without blockign the entier propram.

This port would be relativly straight forward, certainly must less work than say, porting the current code to another language altogether such as C++ or C# and would entail a minimum of rewriting and rearchitecting.  In particular, this kind of same-language port is unlikly to introduce large numbers of new bugs like a cross-language port with rearchitecture would.  I'm confident stability could be maintained.   Once on this new platform, making incremental enhancements to take advantage of multiple processors, not block the mainline sim on internet operations and so on would be relatively easy.

The way IM works currently is that the code does a series of syncronous file operations across the network using the FTP protocol - upload each bot file, down load the incoming ones, upload the local population file, download the others from the other sims.  Each one of these file oeprations is independent and has a timeout of 30 seconds each.  The cumulative timeout is why DB appeaprs to hang for minutes when the server is not responding.  That is, the code gives the server 30 seconds to respond for each request and because of the single threading, the sim blocks, waiting for the operations to complete.

If you hit the IM button to switch out of IM mode, the sim should "release" once the current operation times out and should return to normal non-IM operation within a minute or two (it may have to wait for multiple operations to time out).

I need to do a better job of not doing the rest of the operations when one times out but the main problem is that either our server or the VB6 FTP control that handles the client side communiciaton or both is flaky.  I want to move us to a real FTP server ASAP.  Then I want to port to a newer VB version, make DB multi-threaded and perhaps move to a different underlying protocol other than FTP (for scalability reasons).  One day, we will have to write/run our own custom server I expect but that's a long term plan.

[Numsgil]

VB.NET might as well be a different language, actually.  The syntax is very similar, but there are enough differences in the way different things work that make a straight port difficult.  I did actually try to port Darwinbots to VB.NET once.  There's even a nice wizard for it that you can run your project through.  But the end result was thousands of "errors" in the conversion that would need to be sorted out by hand.

I do think writing the internet controls in VB.NET or C# is the way to go (it doesn't matter which one, they all get compiled to the same base code language).  Using external DLL calls from within the VB code, the program could communicate with the internet module and use it to communicate.

Also, a thought occurs to me: VB lets you, in theory, call any function from any DLL.  I'll bet there's probably a sneaky way to set up multiple threads using DLL calls.

Either way you decide to go, you'll end up with FTP controls in a .NET DLL wrapper.  Go ahead and write just that (I can help too if you like, it can easily serve both our needs) and test it against the current FTP server (sending dummy files of garbage, for instance).  If we run in to similar problems like we have with the current program, we know right away that it's probably the FTP server, and we can fix it with a new server.