Content-type: text/html Set-Cookie: cookiehash=D8TIX1F9GFT8JRTHGSKZDC1UDL31CF7Q; expires=Sat, 21 Nov 2026 00:00:00 GMT; path=/; domain=.drivemeinsane.com
DMI News |
Previous Entry.. Next Entry.. Camserver Finally Done
September 17, 2009 23:30 Ok, that took quite a bit longer than I wanted, but I finally got all of the pages working now with the new camserver. The visitorpage was giving me issues, but it's done now. I do, however, have quite a bit of tweaking to do to make everything work smoothly. There are lots of new fields for both the cam and visitor databases that I need to add to the edit pages, and I still need to make some tweaks to the servers themselves. The camrelay program is crashproof, but it's still using a LOT of memory. I've got a lingering buffer problem that I have yet to figure out. Here's how it works. The relay program is a webserver I wrote, albiet a very primitive one. It accepts a GET request for an image, and part of the url is the cam number. If the cam number is currently unknown to the relay program, it grabs the url from the database, sets up a thread, and connects and grabs an image and holds it in a buffer. My image buffers are arranged as a linked list, with the first element in the list being the most recently recieved image. Image 0 is always the temporary one. When a request comes in, it grabs the first complete image, which is virutally always image 1, but sometimes image 0. Whenever a new request comes in, it adds a connection id to a linked list of locknodes attached to the individual image buffer, and sends the image, meanwhile setting snarfwaiting to 1 which instructs the snarf thread to go grab another image from the webcam host. As soon as that image is complete, it's available to the client to grab, which triggers another snarf, and this process repeats itself until new requests stop coming in. The issue at hand here is the locknode list. That list prevents the image from being purged until all connected clients which were receiving the image have received it, or given up. The problem here is that a connection is likely trying to grab that image, or has quit trying, but neglected to release its locknode. That means the image sticks around.. well... forever, even though nobody is ever going to grab it. This makes the image buffer list just continue to grow. I've solved this problem by simply purging any image buffers that are more than a few minutes old. Nobody is sitting around that long waiting on an image.. however, this shouldn't be necessary, and it also points to a possible issue of a connection thread still sitting open, which is going to also consume system resources over time, although not as quickly as images stored in RAM would. Still, its an issue I still need to debug more.
|