Feature Request: HTTP Keep-Alive for netcams?

Description

Hi,

I use a lightweight server (Linksys NSLU2 running Openslug) which is all I can house in my 'server cupboard'. It only uses 10 Watts so is kinder than running a PC 24/7.

It will run 2 netcams with 2fps at a load average of 3. Basically this means that the machine is still responsive etc and I can log in to it remotely etc. I do not know 'for sure' that I am getting 2fps, though.

If I move to 3 netcams (2 of which are on an Aviosys IP9100A, see new entry in "WorkingDevices") then the load average is 4.5 and I miss frames, the machine becomes unresponsive and cron jobs fail to execute anywhere near on-time. So the machine is overloaded. And I can't speed up the hardware or add more RAM.

I've been told that using HTTP Keep-Alive connections will improve the situation as the overhead of TCP socket set up & tear-down is done infrequently. This is only relevant for Jpeg access mode, since in Mjpeg mode the connection is persistent anyway for the server push to occur. (I must use Jpeg mode, as I'm using a 4 channel video hardware unit. More than one image stream cannot be combined into an mjpeg stream, since there are no identifiers for the sub-streams). By using HTTP Keep-Alive, CPU usage will decrease for netcam access via Jpeg, which is very beneficial for me, and also all other users of netcams. Some netcams have bugs in their mjpeg stream (my DLink DCS-900 has problems after about 1 day, so I do not use that access method). Most netcams are likely to support it, even the cheap device I am using does.

I am going to begin work on this, but I'm not an expert programmer. If someone has the skills then please also attempt it, you may well finish it before me...! Many thanks.

-- SimonW - 22 Jan 2007

Follow up

Comments

I got (made) some time to work on this, and have added my attempt so far, patch SWpatch_keepalive1. It is against SVN version 163. It seems to work well, although I need to test if there is any performance increase. I also need to verify that the correct headers are being sent to the netcam (Motion doesn't print them, so I will use a network sniffer program).

It would be great for others to test this and comment.

Note that the feature is permanently set 'on', further coding is required to create a config-file option to turn it off/on.

@Kenneth: Perhaps this topic needs to change to a Patch now (sorry...)

-- SimonW - 23 Jan 2007

---

Hi Simon ,

The patch seems nice , but it makes me remember an old discussion about performance for netcam . Someone asked in the past to add an option to use HTTP/1.1 request instead of HTTP/1.0 , that was not possible because some devices doesn't support HTTP/1.1 ... but the reason to introduce HTTP/1.1 request is because by default all request are kept alived by default. So before include your patch lets talk about it :

• HTTP/1.0
• HTTP/1.0 + keep alive header
• HTTP/1.1 ( all connection are keep alive by default )

I'm not sure what is the difference between HTTP/1.0 + keep alive header and HTTP/1.1 so maybe we can modify a bit your patch to support all cases as a netcam parameter something :

netcam_http <value>
default : the current implementation using HTTP/1.0 with open/close on each http request.
keep_alive : Use HTTP/1.0 requests with keep alive header to reuse the same connection.
1.1 : Use HTTP/1.1 requests that uses keep alive as default.

-- AngelCarpintero - 23 Jan 2007

---

Yes, I aim to configure this feature in the .conf file in the way you suggest... the permanent enable is just for testing. With time, I can probably get to implement HTTP 1.1 and seeing which of my cams supports it.

I attached a new version, SWpatch_keepalive3. I fixed some assumptions which caused problems with cams that do not support keep-alive, and also one where the keep-alive function was mistakenly operating with a streaming camera (which of course it should not do).

It now has been tested with a D-Link DCS-900 (not -W) which does not support Keep-Alive (with HTTP 1.0 anyway) and also Aviosys IP9100A which does support Keep-Alive on HTTP 1.0. Works ok.

It should still be regarded as alpha code until others have tested it..... And the code contains lots of debug output (I run with -d 99) to explain what's going on. There are also a couple of single-line comments (// Comment) with 'SW' at the end, these are old if statements when I was tuning the keep-alive/no-keep-alive logic. Once the code proves satisfactory, they can be removed.

Testing for performance effect is ongoing.

-- SimonW - 29 Jan 2007

---

I've uploaded an extract of my log for motion since applying the "Keep-Alive for netcams" patch. Looks like it's keeping up with my netcams pretty well. See attachment listed below.

• Feature_Request_2007x_01x_22x_231542.txt: About a day and a half of logs for motion after applying the "HTTP Keep-Alive for netcams" patch

-- JeffGroves - 06 Feb 2007

---

Hello Jeff, Many thanks for the log. It looks like just the errors, of course. I presume you are using the keepalive patch version 3. I am kind of interested in the "Transport endpoint is already connected" which occurs now and then.

If you would like more information to see if your system is keeping up with your netcams, or vice versa, I would recommend my Statistics patch. I've done a bit more work on something started by PeteS.... see StatisticsDataPatch

Using the Statistics patch, you will also be able to see if there's a fps gain with and without (to do 'without', you'll need to remove the patch, or edit it off, & recompile).

I see only a tiny performance improvement on my little server (NSLU2) but with a Sempron 2400, I see more difference:

IP9100A, no keep alive, 1 thread (ie 1 channel accessed) 9.8-10.7fps

IP9100A, no keep alive, 2 threads 11.3-11.9 and 6.4-7.0fps

IP9100A, keep alive patch, 1 thread 10.0-10.9fps

IP9100A, keep alive patch, 2 threads 9.8-11.5 and 7.7-8.3fps

These are with motion svn166+Stats patch, and the IP9100A set to 2 chans. The keep-alive does kind of "balance out" the 2 channels to more equal fps, but the IP9100A is slow hardware. I would be interested to hear the effects on other cams.

I am now working on switching the keep-alive on and off with a config file option, following Angel's guidance above.

-- SimonW - 06 Feb 2007

---

I have finished the changes to the patch to support a config file option as per Angel's suggestion above.

Patch: SWpatch_keepalive4

It should be fully working now and I invite beta testing. Here is the config file section:

# The setting for keep-alive of network socket, should improve performance on compatible net cameras
# default : the historical implementation using HTTP/1.0, closing the socket after each http request.
# keep_alive : Use HTTP/1.0 requests with keep alive header to reuse the same connection
# 1.1 : Use HTTP/1.1 requests that support keep alive as default.

netcam_http default

I've tested it with my netcams using HTTP 1.0, with and without keep-alive, and HTTP 1.1. (However none of my cams support HTTP 1.1). What happens is they respond to motion's HTTP 1.1 request header with a HTTP 1.0 reply header. I guess this is standard backwards-compatibility. The patched code works gracefully in all situations I have tested, the behaviour if a condition occurs that Keep-Alive cannot continue with, it is turned off and Motion continues.

I would recommend anyone testing this patch to also install my StatisticsDataPatch so that any fps increases can be measured. Also it's worth checking the load average on your machine, if practical.

If reporting an error, please try to attach a Motion log file. The best logs are generated with the "-d 9" option on the command line. These include all HTTP headers to and from the camera, and the debug printout of the decisions made. This kind of info will help a great deal... thanks!

-- SimonW - 07 Feb 2007

---

Jeff,

What model is your netcam? Are there details in the WorkingDevices list, and more interestingly a captured stream?

The cause of the errors you see (and I saw one on my system, just once in many days operation) is by reading the code, an unexpected Content-type given by the camera. There may of course also be other causes....

Knowing the camera model, or better, having a stream capture example, will help me ensure the code works for your cam. I note you are running 3 cameras, I only tested with 2 maximum (but that should not be an issue). Do the errors correspond to movement events? Are the errors still occurring or have they ceased?

-- SimonW - 13 Feb 2007

---

I've updated patch adding changes to motion-dist.conf and adapt to conf.c new structure. Also i replace 'default' value by 1.0 i think is better.

-- AngelCarpintero - 19 Nov 2007

---

Thanks for freshening up this patch Angel.

I have recently started looking at this patch again, since I found that standard 'Motion' causes a long list of TCP ports (I counted around 100) in time_wait state in the 'netstat' command output. This ties up resources in maintaining the timers for each one, until they expire and the port number can be reused.

Explanation: For those who are not familiar with TCP port choice on the 'outgoing' side of a conversation, basically the system picks a port number 1024-65535 to connect to the HTTP port (usually port 80) on the destination device. When the conversation finishes, after a timed delay (60 secs usually) the port number can be re-assigned. So if a program opens more than 60 new ports per minute, eventually port numbers will run out. Also the system has to maintain all the timers for them.

# netstat -anop 
-snip-
tcp        0      0 192.168.1.8:42614           192.168.1.200:80            TIME_WAIT   -                   timewait (13.27/0/0)
tcp        0      0 192.168.1.8:42615           192.168.1.200:80            TIME_WAIT   -                   timewait (13.46/0/0)
tcp        0      0 192.168.1.8:42612           192.168.1.200:80            TIME_WAIT   -                   timewait (12.40/0/0)
tcp        0      0 192.168.1.8:42610           192.168.1.200:80            TIME_WAIT   -                   timewait (11.75/0/0)
tcp        0      0 192.168.1.8:42611           192.168.1.200:80            TIME_WAIT   -                   timewait (12.31/0/0)
tcp        0      0 192.168.1.8:42608           192.168.1.200:80            TIME_WAIT   -                   timewait (10.72/0/0)
tcp        0      0 192.168.1.8:42609           192.168.1.200:80            TIME_WAIT   -                   timewait (11.43/0/0)
tcp        0      0 192.168.1.8:42623           192.168.1.200:80            TIME_WAIT   -                   timewait (17.55/0/0)
tcp        0      0 192.168.1.8:42620           192.168.1.200:80            TIME_WAIT   -                   timewait (16.34/0/0)
-snip-

I also used tcpdump & tcptrace to observe the connection to a netcam. It was my non-streaming IP9100 box. With 2 channels, each polled at 1fps, I see 2 new ports opened every second, at 0.1s intervals. After one image transfer, the ports are closed and new ones are opened:

#tcpdump -l test60 | grep "first packet"
        first packet:  Thu Nov 29 08:53:11.382274 2007
        first packet:  Thu Nov 29 08:53:11.468912 2007
        first packet:  Thu Nov 29 08:53:12.391620 2007
        first packet:  Thu Nov 29 08:53:12.469600 2007
        first packet:  Thu Nov 29 08:53:13.408317 2007
        first packet:  Thu Nov 29 08:53:13.487250 2007
        first packet:  Thu Nov 29 08:53:14.417971 2007
        first packet:  Thu Nov 29 08:53:14.506741 2007

# tcptrace -l test
-snip-
TCP connection 5:
        host i:        192.168.1.8:50348
        host j:        192.168.1.200:80
        complete conn: yes
        first packet:  Thu Nov 29 08:53:11.382274 2007
        last packet:   Thu Nov 29 08:53:11.421244 2007
        elapsed time:  0:00:00.038970
        total packets: 65

TCP connection 6:
        host k:        192.168.1.8:50349
        host l:        192.168.1.200:80
        complete conn: yes
        first packet:  Thu Nov 29 08:53:11.468912 2007
        last packet:   Thu Nov 29 08:53:11.506628 2007
        elapsed time:  0:00:00.037716
        total packets: 57

TCP connection 7:
        host m:        192.168.1.8:50350
        host n:        192.168.1.200:80
        complete conn: yes
        first packet:  Thu Nov 29 08:53:12.391620 2007
        last packet:   Thu Nov 29 08:53:12.429515 2007
        elapsed time:  0:00:00.037895
        total packets: 65

TCP connection 8:
        host o:        192.168.1.8:50351
        host p:        192.168.1.200:80
        complete conn: yes
        first packet:  Thu Nov 29 08:53:12.469600 2007
        last packet:   Thu Nov 29 08:53:12.545700 2007
        elapsed time:  0:00:00.076100
        total packets: 58

-snip-

When using HTTP Keep-Alive from my patch, only 2 connections are present in the 'netstat' output for 192.168.1.200. This is much less for the system to maintain. Although I am now using a PC for Motion, so there is quite a lot of processing power available.

(Will add a capture of netstat with Keep-Alive on when is available)

I am also trying to debug an occasional 'freeze' of the IP9100A and it might be that the rapid opening/closing of TCP ports is a factor. I am still investigating and trying to log this freeze with tcpdump.

It must be mentioned again that this will only be seen for non-streaming netcams, ie. those which have an URL ending with .jpg. Streaming ones, using video.cgi or similar, will not show this behaviour.

-- SimonW - 29 Nov 2007

---

I'm going to give a few more test and commit to svn, i have fix some memory leaks already.

-- AngelCarpintero - 04 Dec 2007

---

Commited to svn r290

-- AngelCarpintero - 25 Dec 2007

---

Great news that it's been committed Angel, and thanks for fixing those memory leaks. I do not have the ability to do that.

I've just added to this page a little patch (apply to SVN 292 ... today's) called SWpatch_keepalive-noflood which will limit errors in the log caused by netcam_get_first_header to 1 per minute. When a netcam fails to come up sometimes, I have hundreds of logged errors per second. This is applied in the code at a spot where it says "need to have a dynamic delay here" so it appears to be a known need.

I am running SVN292 with this patch now, but it needs further testing before it goes anywhere. Thanks!

-- SimonW - 02 Jan 2008

---

Nice idea Simon , since there're some people that get flooded by motion warning messages. I started a new topic ( MotionLog ) to allow specify debug level for motion but also planned to implement a temporary ignore as you did, so a defined level of log could be using this ignore very often warnings or do like kernel log "Last message repeated X times".

-- AngelCarpintero - 03 Jan 2008

---

I am still trying to work out why I am experiencing crashes with my IP9100A under polling from Motion. (Both with and without Keep-Alive). I have been logging the TCPIP packets and have been talking to the Yoics team for quite some time now. I am going to try a technique where the Keep-Alive system closes the port and then selects a new one after a number such as 1000 image requests. This might help the IP9100A's webserver to keep its house in order and avoid crashes. So I'm going to write an additional patch to implement this, it may take a few days.

Cross-reference: http://support.yoics.com/viewtopic.php?t=97&postdays=0&postorder=asc&start=0

I don't expect any other cameras that support Keep-Alive to suffer from this problem, as it seems to be specific to the 9100A. Though if anyone is using Keep-Alive and experiences problems, do post, preferably to this thread so all info is in one place.

Cheers, Simon.

-- SimonW - 07 Jan 2008

---

I have found the problem with the IP9100A is limited to one of my two devices. It actually crashes even when no Image requests are submitted to it! It is not a new unit and perhaps it is dying. A reasonably new unit I have (backup) does not crash in the same way.

I have a few patches relating to netcams and will post them separately. I did a lot of studying in diagnosing this problem!

Simon.

-- SimonW - 16 Jan 2008

---

Posted there ?

http://www.lavrsen.dk/twiki/bin/view/Motion/FeatureRequest2008x01x16x222003

Ok Simon, this feature is completed or missing anything yet ? flood maybe ?

-- AngelCarpintero - 17 Jan 2008

Hi Angel, I've updated that page to add the netcam buffer patch with noflood incorporated. The two patches operate on the same area of code, so can't just apply one patch and then the other.

Those svn version numbers are increasing quickly!

-- SimonW - 17 Jan 2008

---

I have added the Keep Alive status flag to the StatisticsDataPatch now that the feature is committed, and it has revealed this bug:

After 1 day and 6 hours (30 hours) exactly, my IP9100A which was running in Keep-Alive then did not return a Keep-Alive header. I haven't checked but in the IP9100's reply to Motion's initial connect request, there is a duration included. I guess this has expired.

So what Motion does is to stop Keep-Alive at that point in time and continue in non-Keep Alive mode.

Here's the log from Motion start to Keep-Alive turning off. (Note that the message is produced by a test-patched version as normally these messages are only output in Debug mode. However, I think that should be changed).

Jan 21 12:56:21 mythserver motion: [0] Processing thread 0 - config file /usr/local/etc/motion.conf
Jan 21 12:56:21 mythserver motion: [0] Unknown config option "night_compensate"
Jan 21 12:56:21 mythserver motion: [0] Unknown config option "low_cpu"
Jan 21 12:56:21 mythserver motion: [0] Processing config file /usr/local/etc/thread1.conf
Jan 21 12:56:21 mythserver motion: [0] Unknown config option "night_compensate"
Jan 21 12:56:21 mythserver motion: [0] Processing config file /usr/local/etc/thread2.conf
Jan 21 12:56:21 mythserver motion: [0] Processing config file /usr/local/etc/thread3.conf
Jan 21 12:56:21 mythserver motion: [0] Motion 3.2.10 Started
Jan 21 12:56:21 mythserver motion: [0] Created process id file /var/run/motion.pid. Process ID is 28886
Jan 21 12:56:21 mythserver motion: [0] Motion running as daemon process
Jan 21 12:56:21 mythserver motion: [0] ffmpeg LIBAVCODEC_BUILD 3345152 LIBAVFORMAT_BUILD 3278080
Jan 21 12:56:21 mythserver motion: [0] Thread 1 is from /usr/local/etc/thread1.conf
Jan 21 12:56:21 mythserver motion: [0] Thread 2 is from /usr/local/etc/thread2.conf
Jan 21 12:56:21 mythserver motion: [0] Thread 3 is from /usr/local/etc/thread3.conf
Jan 21 12:56:22 mythserver motion: [2] Resizing pre_capture buffer to 1 items
Jan 21 12:56:22 mythserver motion: [2] Resizing pre_capture buffer to 2 items
Jan 21 12:56:22 mythserver motion: [3] Resizing pre_capture buffer to 1 items
Jan 21 12:56:22 mythserver motion: [3] Resizing pre_capture buffer to 2 items
Jan 21 12:56:22 mythserver motion: [1] Resizing pre_capture buffer to 1 items
Jan 21 17:26:08 mythserver motion: [1] Error reading image header
Jan 21 20:39:44 mythserver motion: [1] Error reading image header
Jan 22 00:00:00 mythserver motion: [2] Could not create symbolic link [2008/01/22/20080122-000000-snapshot-cam2.jpg]: File exists
Jan 22 00:03:16 mythserver motion: [1] Error reading image header
Jan 22 03:40:07 mythserver motion: [1] Error reading image header
Jan 22 07:00:00 mythserver motion: [2] Could not create symbolic link [2008/01/22/20080122-070000-snapshot-cam2.jpg]: File exists
Jan 22 07:15:23 mythserver motion: [1] Error reading image header
Jan 22 09:00:00 mythserver motion: [1] Could not create symbolic link [2008/01/22/20080122-090000-snapshot-cam1.jpg]: File exists
Jan 22 10:00:00 mythserver motion: [2] Could not create symbolic link [2008/01/22/20080122-100000-snapshot-cam2.jpg]: File exists
Jan 22 12:07:36 mythserver motion: [1] Error reading image header
Jan 22 16:33:33 mythserver motion: [1] Error reading image header
Jan 22 18:56:20 mythserver motion: [2] Removed netcam_keepalive flag because no Keep-Alive header received.
Jan 22 18:56:20 mythserver motion: [3] Removed netcam_keepalive flag because no Keep-Alive header received.
Jan 22 18:56:52 mythserver motion: [0] webhttpd.c: getsockopt for receive buffer returned error.: Bad file descriptor
Jan 22 19:54:25 mythserver motion: [0] webhttpd.c: getsockopt for receive buffer returned error.: Bad file descriptor
Jan 22 19:55:25 mythserver motion: [1] Error reading image header
Jan 22 19:55:26 mythserver motion: [0] webhttpd.c: getsockopt for receive buffer returned error.: Bad file descriptor
Jan 22 20:07:33 mythserver motion: [0] webhttpd.c: getsockopt for receive buffer returned error.: Bad file descriptor
Jan 22 20:18:40 mythserver motion: [0] webhttpd.c: getsockopt for receive buffer returned error.: Bad file descriptor
Jan 22 20:40:52 mythserver motion: [0] webhttpd.c: getsockopt for receive buffer returned error.: Bad file descriptor
Jan 22 20:58:03 mythserver motion: [0] webhttpd.c: getsockopt for receive buffer returned error.: Bad file descriptor

There is still a little more work to do, to get Motion to keep a record of the duration supplied by the IP camera and ensure that before that time, it closes the socket and re-opens another one (but still with Keep-Alive turned on).

This shouldn't be too arduous to do, I will work on it when I get the time. I already had a small patch that simply counts frames, and recycles the socket after a configurable number such as 1000. However that's only 15 minutes at 1 fps.

-- SimonW - 22 Jan 2008

---

First attempt at fixing the problem. Not quite there yet, as the log shows:

Jan 24 11:45:50 mythserver motion: [0] Thread 1 is from /usr/local/etc/thread1.c       onf
Jan 24 11:45:50 mythserver motion: [0] Thread 2 is from /usr/local/etc/thread2.c       onf
Jan 24 11:45:50 mythserver motion: [0] Thread 3 is from /usr/local/etc/thread3.c       onf
Jan 24 11:45:50 mythserver motion: [2] Resizing pre_capture buffer to 1 items
Jan 24 11:45:51 mythserver motion: [2] Resizing pre_capture buffer to 2 items
Jan 24 11:45:51 mythserver motion: [3] Resizing pre_capture buffer to 1 items
Jan 24 11:45:51 mythserver motion: [3] Resizing pre_capture buffer to 2 items
Jan 24 11:45:51 mythserver motion: [1] Resizing pre_capture buffer to 1 items
Jan 24 16:36:05 mythserver motion: [1] Error reading image header
Jan 24 18:00:00 mythserver motion: [3] Could not create symbolic link [2008/01/2       4/20080124-180000-snapshot-cam3.jpg]: File exists
Jan 24 20:38:44 mythserver motion: [1] Error reading image header
Jan 25 00:33:55 mythserver motion: [1] Error reading image header
Jan 25 04:00:00 mythserver motion: [2] Could not create symbolic link [2008/01/2       5/20080125-040000-snapshot-cam2.jpg]: File exists
Jan 25 04:41:10 mythserver motion: [1] Error reading image header
Jan 25 07:00:00 mythserver motion: [3] Could not create symbolic link [2008/01/2       5/20080125-070000-snapshot-cam3.jpg]: File exists
Jan 25 09:23:38 mythserver motion: [1] Error reading image header
Jan 25 10:00:00 mythserver motion: [1] Could not create symbolic link [2008/01/2       5/20080125-100000-snapshot-cam1.jpg]: File exists
Jan 25 14:43:07 mythserver motion: [1] Error reading image header
Jan 25 17:45:49 mythserver motion: [3] No Keep-Alive header received from netcam       . Will try to restart Keep-Alive next time round. If this message occurs continu       ously, turn off Keep-Alive in conf file.
Jan 25 17:45:49 mythserver motion: [3] Removed netcam_keepalive flag because 'Co       nnection: close' header received. Will not attempt to restart Keepalive.
Jan 25 17:45:49 mythserver motion: [2] No Keep-Alive header received from netcam       . Will try to restart Keep-Alive next time round. If this message occurs continu       ously, turn off Keep-Alive in conf file.
Jan 25 17:45:49 mythserver motion: [2] Removed netcam_keepalive flag because 'Co       nnection: close' header received. Will not attempt to restart Keepalive.
Jan 25 17:48:12 mythserver motion: [0] webhttpd.c: getsockopt for receive buffer        returned error.: Bad file descriptor
Jan 25 17:58:17 mythserver motion: [0] webhttpd.c: getsockopt for receive buffer        returned error.: Bad file descriptor

So I have to try another edit. It takes 30 hours per try to test this patch

-- SimonW - 25 Jan 2008

---

Angel, I have just attached the patch SWpatch_keepalive-3.2.10update which I am pretty sure does what is needed. I have seen it successfully work for 1 cycle (30 hours) now am waiting for a few more cycles to go by, hopefully it will work fine.

The keep-alive logic has been altered to do the following:

• If keep-alive is turned on, and netcam returns a Close header but has never sent a Keep-Alive header, then Keep-alive is disabled and not re-tried ever. (Edited to clarify on 31 Jan 08)
• If keep-alive header is returned from the netcam, that is taken as a signal that it's ok to use. Motion continues using Keep-alive until a Connection: close header is received. On my Aviosys IP9100A, with Yoics firmware, that takes 30 hours (to within 5 seconds). A flag is set, the socket is closed and then re-opened with Keep-Alive enabled again.

And that seems to work, but I want to let it run for some more days. If all is well, I'll post here, and I guess this should be committed pretty soon as this fixes a shortcoming in the original keepalive commit. I'd like it if others could test and confirm, of course, but I don't know how many are using keep-alive.

Cheers, Simon.

-- SimonW - 30 Jan 2008

---

Simon , thanks !

I'll wait until your verify that patch works fine before merge it in trunk.

-- AngelCarpintero - 31 Jan 2008

---

Well I have put it through some long tests as follows:

Http 1.1 mode. Run for over 90 hours with 2 netcams. Went through 3 cycles of the IP9100 Keep-alive ending and being renewed.

Jan 29 15:23:38 mythserver motion: [0] Motion 3.2.10 Started
Jan 29 15:23:38 mythserver motion: [0] Created process id file /var/run/motion.pid. Process ID is 13066
... snip ....
Jan 29 15:23:38 mythserver motion: [0] Motion running as daemon process
Jan 30 21:23:36 mythserver motion: [2] Keep-Alive has reached end of valid period. Motion will close netcam, then resume Keep-Alive with a new socket.
Jan 30 21:23:37 mythserver motion: [3] Keep-Alive has reached end of valid period. Motion will close netcam, then resume Keep-Alive with a new socket.
Jan 30 21:23:37 mythserver motion: [2] Closing netcam socket as Keep-Alive time is up (camera sent Close field). A reconnect should happen.
Jan 30 21:23:38 mythserver motion: [3] Closing netcam socket as Keep-Alive time is up (camera sent Close field). A reconnect should happen.
Feb  1 03:23:36 mythserver motion: [2] Keep-Alive has reached end of valid period. Motion will close netcam, then resume Keep-Alive with a new socket.
Feb  1 03:23:37 mythserver motion: [2] Closing netcam socket as Keep-Alive time is up (camera sent Close field). A reconnect should happen.
Feb  1 03:23:37 mythserver motion: [3] Keep-Alive has reached end of valid period. Motion will close netcam, then resume Keep-Alive with a new socket.
Feb  1 03:23:38 mythserver motion: [3] Closing netcam socket as Keep-Alive time is up (camera sent Close field). A reconnect should happen.
Feb  2 09:23:36 mythserver motion: [2] Keep-Alive has reached end of valid period. Motion will close netcam, then resume Keep-Alive with a new socket.
Feb  2 09:23:37 mythserver motion: [2] Closing netcam socket as Keep-Alive time is up (camera sent Close field). A reconnect should happen.
Feb  2 09:23:37 mythserver motion: [3] Keep-Alive has reached end of valid period. Motion will close netcam, then resume Keep-Alive with a new socket.
Feb  2 09:23:38 mythserver motion: [3] Closing netcam socket as Keep-Alive time is up (camera sent Close field). A reconnect should happen

Http 1.0 with keepalive. Run for 1 cycle ( just over 30 hours) with 3 netcams.

Feb  6 22:28:58 mythserver motion: [0] Motion 3.2.10 Started
Feb  6 22:28:58 mythserver motion: [0] Created process id file /var/run/motion.pid. Process ID is 6663
Feb  6 22:28:58 mythserver motion: [0] Motion running as daemon process
... snip ...
Feb  8 04:28:56 mythserver motion: [4] Keep-Alive has reached end of valid period. Motion will close netcam, then resume Keep-Alive with a new socket.
Feb  8 04:28:56 mythserver motion: [3] Keep-Alive has reached end of valid period. Motion will close netcam, then resume Keep-Alive with a new socket.
Feb  8 04:28:56 mythserver motion: [2] Keep-Alive has reached end of valid period. Motion will close netcam, then resume Keep-Alive with a new socket.
Feb  8 04:28:57 mythserver motion: [4] Closing netcam socket as Keep-Alive time is up (camera sent Close field). A reconnect should happen.
Feb  8 04:28:57 mythserver motion: [3] Closing netcam socket as Keep-Alive time is up (camera sent Close field). A reconnect should happen.
Feb  8 04:28:57 mythserver motion: [2] Closing netcam socket as Keep-Alive time is up (camera sent Close field). A reconnect should happen.

Http 1.0, run for about 1 hour with 3 netcams. Worked fine, but number of TCP ports in 'pending close' state was around 110 at that time.

Well I am happy with it so I recommend committing It is in my production server so is used 24/7, and I'm able to maintain it if anyone finds a problem. Simon.

-- SimonW - 08 Feb 2008

---

Should just add that in http 1.0 mode, around 110 tcp ports pending close after an hour running Motion is a perfectly normal effect of using http 1.0 with a non-streaming camera...

In the future, perhaps we could tweak the TCP parameters of ports opened without keep-alive to last only 5 seconds, or so.

Simon.

-- SimonW - 08 Feb 2008

---

Thanks Simon

I've fixes some minor errors in you patch and reorganize the aliveflag & closeflag, committed to trunk svn r312.

I'll merge with 3.2.10 with other changes i did in trunk.

-- AngelCarpintero - 09 Feb 2008

---

I have been running this patch continuously for a month now, and have only seen this glitch:

Mar  9 08:43:09 mythserver motion: [2] Keep-Alive has reached end of valid period. Motion will close netcam, then resume Keep-Alive with a new socket.
Mar  9 08:43:09 mythserver motion: [4] Keep-Alive has reached end of valid period. Motion will close netcam, then resume Keep-Alive with a new socket.
Mar  9 08:43:09 mythserver motion: [3] Keep-Alive has reached end of valid period. Motion will close netcam, then resume Keep-Alive with a new socket.
Mar  9 08:43:10 mythserver motion: [3] Closing netcam socket as Keep-Alive time is up (camera sent Close field). A reconnect should happen.
Mar  9 08:43:10 mythserver motion: [2] Closing netcam socket as Keep-Alive time is up (camera sent Close field). A reconnect should happen.
Mar  9 08:43:10 mythserver motion: [4] Closing netcam socket as Keep-Alive time is up (camera sent Close field). A reconnect should happen.
Mar 10 14:43:09 mythserver motion: [4] Keep-Alive has reached end of valid period. Motion will close netcam, then resume Keep-Alive with a new socket.
Mar 10 14:43:09 mythserver motion: [2] Keep-Alive has reached end of valid period. Motion will close netcam, then resume Keep-Alive with a new socket.
Mar 10 14:43:09 mythserver motion: [3] Keep-Alive has reached end of valid period. Motion will close netcam, then resume Keep-Alive with a new socket.
Mar 10 14:43:10 mythserver motion: [4] Closing netcam socket as Keep-Alive time is up (camera sent Close field). A reconnect should happen.
Mar 10 14:43:10 mythserver motion: [2] Closing netcam socket as Keep-Alive time is up (camera sent Close field). A reconnect should happen.
Mar 10 14:43:10 mythserver motion: [3] Closing netcam socket as Keep-Alive time is up (camera sent Close field). A reconnect should happen.
Mar 10 20:52:14 mythserver motion: [3] Removed netcam Keep-Alive flag due to apparent closed HTTP connection.
Mar 11 20:43:13 mythserver motion: [2] Keep-Alive has reached end of valid period. Motion will close netcam, then resume Keep-Alive with a new socket.
Mar 11 20:43:13 mythserver motion: [4] Keep-Alive has reached end of valid period. Motion will close netcam, then resume Keep-Alive with a new socket.
Mar 11 20:43:14 mythserver motion: [2] Closing netcam socket as Keep-Alive time is up (camera sent Close field). A reconnect should happen.
Mar 11 20:43:14 mythserver motion: [4] Closing netcam socket as Keep-Alive time is up (camera sent Close field). A reconnect should happen.
Mar 13 02:43:13 mythserver motion: [2] Keep-Alive has reached end of valid period. Motion will close netcam, then resume Keep-Alive with a new socket.

Note the 'apparent closed HTTP connection'. The HTTP Status page also shows that Keep-Alive is still 'on' for other threads accessing the same IP9100A (2 and 4), but it is off for thread 3.

Motion was started on 6th March when the machine was last booted, and I've never seen that message before. It means that Keep-Alive was turned off following a non-OK response code (anything other than 200) from the request for an image. Perhaps under these circumstances, more should be output, and it might well be possible to continue with Keep-Alive. I should check the result code more carefully and take a more suitable action.

I will take a look at a solution to this, so that Motion can "take it in its stride" and continue reliably if at all possible.

Simon.

-- SimonW - 13 Mar 2008

---

Just a note to say I haven't seen this message again in the whole of April so far. I still think it might be a return code from the HTTP request to the netcam, of something other than 200 (OK).

An opportunity for a further improvement of Keep-alive would be to work out what the best thing to do, if a non-200 return code occurs. At present, stopping Keep-alive is more of a 'safety choice' and may not be needed.

Another possible improvement that occurred to me, for the future, is if Motion receives a SIGHUP, to restart itself, before closing one more HTTP request could be sent to the netcam with the "Connection: close" setting. This would allow the netcam to close any internal timers etc, as when Motion restarts it will almost certainly use a different outgoing port number, leaving an 'orphan'. It is not essential at all, as all TCP devices will close down & clean up old/orphaned sockets when their timers expire, but this can be measured in tens of minutes.

-- SimonW - 25 Apr 2008

---