Darwinbots Forum
Code center => Bugs and fixes => Topic started by: Numsgil on December 20, 2007, 07:17:25 PM
-
After running for a few hours, my Darwinbots program suddenly won't connect to the internet. Resetting the program fixes this, but then it'll happen again a few hours later. The first hint that something isn't right in the log says something like "error disconnecting".
-
I wish I knew what the issue was with this. I've tried lots of different things. I'll keep at it I guess.
-
It happens under Linux/Wine too, so I betcha it isn't a software conflict.
-
Is there a way to reallocate the FTP control periodically? At least so I don't have to reset the program all the time?
-
Not that I've found. The VB Inet control isn't unloadable and calling Inet.Cancel doesn't address it.
-
I think this is getting worse the more we run it. Have you thought about that maybe it's the guys who you have bought the server space from that might have some antispam protection that tries to stop this. It was mensioned here before. Maybe you could talk to them or find a better server.
Yesterday when I was running in IM I found that the sim had frozen and generated all sorts of errors in the log. After 6 min with the sim not moving I gave up and quitted. There were only 25 vegs in it. Nothing came in or out.
-
The FTP server is hosted on the same place as our webspace: GoDaddy. I called tech support a while ago when Eric was having problems. They said that the FTP connection should be up 100% of the time. If it's not, it's a tech problem. However I don't think these issues are related to the FTP side of things. I'm thinking it's something wrong with the way the VB control works.
-
My theory is that there's a session leak, either in the control itself or in the way I handle various failures when two sims try to access the same file for example. A session or two leaks, and since our FTP server only allows 2 sessions per IP address, the third session hangs and starts timing out. It shouldn't do this, but perhaps the control doesn't know how to handle this specific return code or similar. The "hang" effect is FTP session operations timing out. I have two time out timers going for FTP operations that take too long, one built into the control itself (Inet.StillExecuting) and one I built myself using a separate timer control. I loop waiting for .StillExecuting to go false, handling events in the loop. Sometimes the control just never comes back I.e. StillExecuting never goes false. I time out myself and try to cancel the operation, but if the control or server isn't listening... that is when you see the "Still Exceuting previous operation" message.
I'll try playing a little with error handling. Once we move to another server which allows more than 2 sessions per IP, things may suddenly get better or not. I hope to fix this specific issue, but we are going to need to write a server and build ourselves our own protocol at some point if we ever want to scale this up large...
-
I still think for a long term solution we should explore some sort of PHP script that feeds data in to a database. That way you wouldn't even need to use Darwinbots to check to see what the current state of the megasim is.
-
That would be fine for stats but we still need to move bots between sims, which is the bulk of what we do today via FTP.
-
I haven't explored it totally yet, but I'm pretty sure you can hook up a file upload to a PHP page. The program would call the web page with the specified file and it would get uploaded and stored. Likewise, the program could call up a similar page to download a bot.
-
bump to bring open bug to first page
-
Another possible solution: build a separate C# DLL that handles communicating with the FTP server. Have Darwinbots call this separate internet handling mechanism. The DLL could run as a separate thread, solving issues with IM freezing the sim and making the program unresponsive periodically. C# also generally has better internet communications controls with better debugging.
IM is so removed from the actual program, getting the two to interface would be easy. All you need is for DB to tell it a file to try and upload, give it the go-ahead to download, and a way for the DLL to send back status reports (server unreachable, etc. etc.)
The downside, obviously, is that now you'd have to support two programs. But then the IM controls would change so infrequently you could just have it as part of a base installer, and work upgrades like you've been doing. Renaming the DLL with each new DLL release solves problems of the VB program trying to access an invalid version, if that's ever a problem.