getWizPnP - Beyonwiz recording downloader

[sub3R]

Thanks Peter, at this stage I’ll persevere.
I have enough recordings on Wiz_01 to see a pattern like: ‘start getwizpnp --check > checking/listing for 1min30sec > stalled for 3min > continued checking/listing for 1min30sec > stalled for 3min > continued checking/listing’. After each stall it lists a ‘missing data file’.

When listing the recordings using getwizpnp --check, Process Explorer shows getWizPnP.exe dropping from between 39% - 63% CPU use down to nothing (not even 0%) when it stalls for 3min before listing the missing data file. After it starts listing the recordings again (including the missing data file) it returns to between 39% - 63% CPU use again. GetWizPnP.exe I/O reads are 839 with I/O writes 0 (839 I/O reads coming up after listing the first 2 or 3 recordings in the list). ‘System Idle Process’ is usually between 96% - 98% CPU use without hardly any activity & this comes back up to this when getwizpnp --check stalls.

I’ll get more info on this if it helps because I can confuse it at the stall point by doing a ^C then immediately running --check again. I can get either of the following:

Code: Select all

C:\>getwizpnp -a -H (fixed IP address) --verbose --check
Bad WizPnP response: No device description returned from http://(fixed IP address):49
152/tvdevicedesc.xml
Can't get a device description for (fixed IP address)

C:\>getwizpnp -a -H (fixed IP adddress) --verbose --check
Connecting to Wiz_02 (fixed IP address:49152)
Fetch of index for http://(fixed IP address):49152 failed

I decided to run ‘getwizpnp -a -H (fixed IP address) --list --verbose -x --debug=trunc’ on Wiz_01 (this has the most recordings) to see if I could get it to stop at 1min 30sec but it continued listing all the recordings without stalling – total time to do this was 5min exactly. So at this stage the problem appears to be unique to --check. Do both commands only do one initial request or does --list --dubug=trunc keep making more requests?

I haven’t ruled out something on the XP PC blocking --check for a while, but if this is so then why not --list --dubug=trunc?

I’ll see what’s been happening in whatever log files I can find. Any suggestions gratefully accepted.

I have to go out shortly so I’ll be leaving this for some time.

[sub3R]

Peter, I think there’s a bug when I run the following getWizPnP command:
getwizpnp -a -H (fixed IP address) --list --verbose -x --debug=trunc,stat,pids Group-B

Code: Select all

7mate Taree: Group-B Rally Cars (keep)/600 horsepower, ... *AC3
    Index name: recordings/Keep_watched/Group-B Rally Cars (keep) Jan.26.2012_15.58
    Thu Jan 26 15:58:00 2012 - Thu Jan 26 17:26:28 2012
    playtime:   88:28    recording size:   5999.5 MB    bit rate:   9.0 Mb/s
    autoDelete: Never
    magic: 0x1062 version: 5
    vidPID: 4630 (0x1216)  audPID: 4632 (0x1218)  AC3
    PCRPID: 4630 (0x1216)  PMTPID:  463 (0x01cf)
    Stat recording end offset:     -1
    Recording start offset:              262144
    Recording end offset:            5999722496
    File  File Offset       Size     Rec Offset Dup Flags Start Time
    0021      3452928   30101504         262144             00:00:00
    0022            0   33554432       30363648             00:00:39
    ...
    0198            0   33554432     5935943680             01:27:37
    0199            0   29962240     5969498112             01:28:07

Isn’t the Stat recording end offset wrong? Shouldn’t this be something like 5999460352? I’m comparing this to the same recording here when the offsets were going negative.
So far I can see a few other recordings where the Stat recording offset is showing a negative figure. This is the first time I've used --debug=stat.

It calculates correctly for small recordings:

Code: Select all

Stat recording end offset: 189399040
Recording start offset:              262144
Recording end offset:             189399040
File  File Offset       Size     Rec Offset Dup Flags Start Time
0000            0   33554432         262144             00:00:00
0001            0   33554432       33816576             00:01:05
...
0004            0   33554432      134479872             00:03:49
0005            0   21364736      168034304             00:04:43

[prl]

Looks like I haven't fixed all the offset printing

[sub3R]

Peter, I don’t know if this is a problem or just the way the last file is calculated in (keep A-B only’ edited recordings.

In addition to the Stat recording offset being ‘-1’ in the first example of my last post, did you notice the difference of 262144 (start offset) between the ‘recording end offset’ of 5999722496 & the last file totals of 5999460352 (5969498112 + 29962240)? This is a ‘keep A-B only’ edited recording.
This result is typical of ‘keep A-B only’ edited recordings I have looked at so far, even <2GB recordings with a ‘Stat recording offset’ = last file totals.

The second example works out correct; 189399040 (recording end offset) compared to last file totals of 189399040 (168034304 + 21364736). This is a ‘keep A-B only’ unedited recording.

The ABC1 ‘Dalziel And Pascoe’ recording is also ‘keep A-B only’ unedited & shows the same results as the second example (recording end offset = last file totals). This recording has a negative number for the ‘Stat recording end offset’.

The recordings that look correct to me (last file totals = Stat recording offset = Recording end offset) are <2GB, ‘keep A-B only’ unedited recordings.

I can post examples if it would help.

[prl]

I don't think that there's any guarantee in the firmware that

last file totals = Stat recording offset = Recording end offset

The stat file contents and the recording end offset are simply printed from their respective fields in the stat file and the header.tvwiz file. They're not the result of any calculation, apart from the bit-twiddling that's required because Perl can only extract 32-bit binary values, and offsets must be assembled from two of them to create a 64-bit value.

I'm uncertain what the purpose of the stat file is, anyway. It only seems to contain some end-of-recording value, which is continuously updated during recording. Once the recording is made, then I have no idea what it is used for, or eve whether it is then intended to have a meaningful end-of-recording value.

Similarly, I've sometimes seen (when I've actually bothered to calculate it) that

last file totals != Recording end offset

The trunc file numbers aren't manipulated by getWizPnP either (except as above to create the offset value), so if there's an inconsistency (apart from -1 being printed for the stat offset), it's probably real.

The time offsets printed in --debug=trunc are the result of interpolation.

[sub3R]

Ok, that’s good information – so it isn’t another problem. The part that had me interested was if there was any difference it was always = 262144, which is the start offset.
I’ll put it down to a wiz ‘feature’.

Back to the getwizpnp --check problem:
I just tried running getwizpnp --check in ‘Windows Safe Mode with Networking’ with the Internet connection disconnected & I still get the same problem, only it appears to stall at 1min 25sec instead of at 1min 30sec. In this mode Process Explorer shows GetWizPnp.exe only using between 1% to 24% CPU use & at times dropping out for a very short period to nothing.

In ‘Windows Safe Mode with Networking’ mode, Process Explorer only shows the following processes being used; System Idle, Interrupts, DPCs, Issas.exe, svchost.exe, explorer.exe\procexp.exe, aawservice.exe (which I suspended), cmd.exe & getWizPnP.exe.

Process Explorer shows that the Performance Data for getWizPnP.exe stops being updated when it stalls until it starts listing again. ‘Windows Task Manager > Networking’ graph also shows no network activity when it is stalled, but it picks up again after it starts listing.

‘Process Explorer > getWizPnP.exe > properties > threads’ only lists the following (with start addresses); ‘getWizPnp.exe+0x1280’ & ‘mswsock.dll!WSPStartup+0x102b’.
‘Process Explorer > getWizPnp.exe > properties > threads > getWizPnP.exe’ shows: Prior to it stalling; ‘State: Ready’, when it stalls; ‘State: Wait:Executive', & after it starts listing; ‘State: Ready’ again.
‘Process Explorer > getWizPnp.exe > properties > threads > mswsock.dll’ seems to show; ‘State: Wait:WrQueue' all the time, although it could quickly change while ‘properties’ are being reselected to show if these ‘states’ have updated.

I still have to go through any log files I can find.

If the wiz stops sending any information that has been requested by getwizpnp --check, or this information has been sent but hasn’t been received by getWizPnP, does getWizPnP --check time out, if so do you know how long before it should time out? Also, if it times out should it terminate & return to the ‘cmd’ prompt.

[prl]

The timeouts are probably simply the default timeouts for the HTTP connection. For each entry in the trunc file, getWizPnP does a HTTP HEAD request to check the file size. The HTTP HEAD request is the same as the normal GET request, but only the header of the HTTP response is sent back, not the body (containing the document contents).

getWizPnP does this by a single call to the LWP::Simple package that handles all the HTTP requests in getWizPnP. I don't have any idea why the requests would fail like this. The same request is used to check the sizes of the recording header files as well, but of course there are far more checks on the recording data file sizes.

The default HTTP request timeout in LWP::Simple is 180 sec, consistent with what you've observed simply being a timeout while waiting for a response to the request. While waiting for a response to a HTTP request I'd expect getWizPnP to have no CPU usage, and to be (as it appears to be) in a wait state in the kernel, though that's probably reflected back to the wait in the mswsock (MicroSoftWindowsSOCKets) DLL. Unfortunately I don't know enough about Windows to know whether that's expected behaviour or not.

Why there's this timeout, I don't know.

[sub3R]

Ok thanks, 180sec timeout could be about right seeing I’ve just been using the second hand on the watch & it’s hard to know exactly when it stalls or waits, or even exactly when it starts or restarts. So I can assume it shouldn't terminate & return to the ‘cmd’ prompt after the timeout period.

I’m not sure where to from here. I still don’t know if the problem is unique to Window XP sp3 home edition or my PC/LAN setup (but the same LAN with the Vista Notepad isn’t an issue).

This may help:
I wonder if someone else running Windows XP (preferably home edition) connected via a wired LAN to a wiz running .350 f/w could give this a shot to see if getwizpnp --check stalls after approx 1min 25sec for 3 minutes before listing a ‘missing data file’ & then continuing?
The getWizPnP command I’ve been using from the ‘start > run > cmd’ prompt is: getwizpnp -a -H (enter the wiz’s IP address here without brackets) --verbose --check
I have the latest Windows version (0.5.3beta2) of getWizPnP.exe downloaded from here, extracted, installed, then a copy of getWizPnP.exe copied under the root directory of c:\ drive. (if not sure; <Ctrl><C> will terminate getWizPnp).

[prl]

I've had a go at trying to run getWizPnP off an XP LiveCD, but:

• If I run the LiveCD on the bare machine (MacBook Pro), I can get a copy of getwizPnP onto it, but its networking doesn't work (probably needs drivers for the Mac networking hardware).
• If I run it in VirtualBox, networking works, but I can't access any native volumes on my Mac without installing VB User Additions. However, User Additions won't install when I'm running off a LiveCD

Edit: I've just remembered how I got a runnable copy of Beyonwiz Remote Updater to run in the XP LiveCD in VirtualBox (by making a CD image).

[prl]

OK, I've been able to reproduce the "data file missing" bug in --check.

It took about 2 minutes from start to hang, but then 3 minutes from the start of the hang to getting the error. I got another hang some time later, but I didn't time it. I wonder whether it's the number of requests rather than the time that's triggering the problem. I'm not sure what I can do about it. I'll try to extract more debugging information if I can.

[prl]

I've found the problem with large stat file offsets printing incorrectly on Windows and fixed it in my development version.

[sub3R]

That’s great news about the --check problem. Thanks for trying that.
I’ve never had it go for longer than 1min 30sec before stalling but I think I only timed it once on the 2nd S1 – I’ll time it again. Three minutes is pretty right though before the ‘missing data file’ gets listed. I’ll also see if I can see anything different between the two wizzes in Process Explorer when running --check. One wiz has more longer recordings than the other.

Good news about the stat file offset problem. You've had a successful day.

[sub3R]

I can’t see any obvious differences in Process Explorer running getwiz --check on either wiz.

I can get slightly different times before getting a wait condition. Running --check on Wiz_02 it took 1min 30sec to list 29 recordings before it stalled with --sort=dd, & 1min 40sec to list 31 recordings using --sort=da. Running --check on Wiz_01 it took 1min 30sec to list 37 recordings before it stalled with --sort=dd, & 1min 35sec to list 46 recordings using --sort=da. Once I got 1min 10sec between the wait conditions on Wiz_01, I didn’t count the recordings listed though.

Late tonight I might record a few long HD recordings & a few long SD recordings & tomorrow see what times & how many recordings are listed before the wait condition.

[prl]

I can’t see any obvious differences in Process Explorer running getwiz --check on either wiz.

I can get slightly different times before getting a wait condition. Running --check on Wiz_02 it took 1min 30sec to list 29 recordings before it stalled with --sort=dd, & 1min 40sec to list 31 recordings using --sort=da. Running --check on Wiz_01 it took 1min 30sec to list 37 recordings before it stalled with --sort=dd, & 1min 35sec to list 46 recordings using --sort=da. Once I got 1min 10sec between the wait conditions on Wiz_01, I didn’t count the recordings listed though.

Late tonight I might record a few long HD recordings & a few long SD recordings & tomorrow see what times & how many recordings are listed before the wait condition.

It's the total number of requests I was thinking of, not the number of recordings - each recording has requests for its header files, and then for each of its data files, but it's still speculation. I intend to count them

[sub3R]

Fair enough, I was trying to pin it down by the number of data files. The recordings didn’t help anyway.

I don’t know if this is any help:

Process Monitor v.2.9.4 (without any filters set) shows when getwizpnp --check stalls (note two TCP Disconnects; ‘PC:2940’ followed by ‘PC:2941’ - no send or receive prior to the last one, & also there are a lot of 'Name Not Found' every time it tries to read from the registry). There wasn’t any getWizPnP.exe activity after the last row shown when it stalled.
I have replaced some information with ‘PC’ & ‘DP-S1’ to fit in the one row.

Code: Select all

Time of Day        Process Name    PID    Operation        Path                 Result           Detail
...
...
21:15:07.3175884	getWizPnP.exe	3768	TCP Send         PC:2939 -> DP-S1	  SUCCESS	       Length: 222
21:15:07.3211266	getWizPnP.exe	3768	TCP Receive  	 PC:2939 -> DP-S1	  SUCCESS	       Length: 199
21:15:07.3230551	getWizPnP.exe	3768	TCP Disconnect   PC:2939 -> DP-S1	  SUCCESS	       Length: 0
21:15:07.3249362	getWizPnP.exe	3768	RegOpenKey   	 HKCU\Software\Perl	NAME NOT FOUND	Desired Access: Read
21:15:07.3249734	getWizPnP.exe	3768	RegOpenKey       HKLM\Software\Perl	NAME NOT FOUND	Desired Access: Read
21:15:07.3294174	getWizPnP.exe	3768	TCP Send   	   PC:2940 -> DP-S1	  SUCCESS	       Length: 222
21:15:07.3329430	getWizPnP.exe	3768	TCP Receive	   PC:2940 -> DP-S1	  SUCCESS	       Length: 199
21:15:07.3349008	getWizPnP.exe	3768	TCP Disconnect	PC:2940 -> DP-S1	  SUCCESS	       Length: 0
21:15:07.3367933	getWizPnP.exe	3768	RegOpenKey	    HKCU\Software\Perl	NAME NOT FOUND	Desired Access: Read
21:15:07.3368284	getWizPnP.exe	3768	RegOpenKey	    HKLM\Software\Perl	NAME NOT FOUND	Desired Access: Read
21:15:07.3389961	getWizPnP.exe	3768	TCP Disconnect	PC:2941 -> DP-S1	  SUCCESS	       Length: 0
21:15:07.3485759	getWizPnP.exe	3768	RegOpenKey	    HKCU\Software\Perl	NAME NOT FOUND	Desired Access: Read
21:15:07.3486112	getWizPnP.exe	3768	RegOpenKey	    HKLM\Software\Perl	NAME NOT FOUND	Desired Access: Read

Edit: The ‘Name Not Found’ isn’t a problem for the Windows Vista Notebook – it shows the same messages. But the Notebook does seem to do a few other things that the XP PC doesn't seem to do when running getwizpnp --check. When run on the XP PC it does a lot of consecutive registry reads & displays 'Name Not Found' each time.

[sub3R]

For reference, Process Monitor v.2.9.6 (without any filters set) shows getwizpnp --check running on the Windows Vista Notebook. I have replaced some information with ‘Notebook’ & ‘DP-S1’ to fit in the one row.

Code: Select all

Time of Day           Process Name    PID    Operation        Path                      Result           Detail
...
10:21:33.7445847 AM	getWizPnP.exe	5312	RegOpenKey	    HKCU\Software\Perl     	NAME NOT FOUND	Desired Access: Read
10:21:33.7446097 AM	getWizPnP.exe	5312	RegOpenKey	    HKLM\Software\Perl     	NAME NOT FOUND	Desired Access: Read
10:21:33.7466481 AM	getWizPnP.exe	5312	TCP Disconnect   Notebook:51203 -> DP-S1	SUCCESS       	Length: 0
10:21:33.7500579 AM	getWizPnP.exe	5312	TCP Connect	   Notebook:51204 -> DP-S1	SUCCESS       	Length: 0
10:21:33.7519283 AM	getWizPnP.exe	5312	TCP Send	      Notebook:51204 -> DP-S1	SUCCESS       	Length: 212
10:21:33.7552642 AM	getWizPnP.exe	5312	TCP TCPCopy	   Notebook:51204 -> DP-S1   SUCCESS       	Length: 199
10:21:33.7553952 AM	getWizPnP.exe	5312	TCP Receive	   Notebook:51204 -> DP-S1	SUCCESS       	Length: 199
10:21:33.7588467 AM	getWizPnP.exe	5312	TCP Disconnect   Notebook:51204 -> DP-S1	SUCCESS       	Length: 0
...

[prl]

The Registry operations aren't something that's in the code that I've written in getWizPnP. But I have no idea whet the Perl package I use, or the DLLs they use do in any deep detail. It could be that the registry accesses are simply to find out whether getWizPnP is authorised to make Internet connections (which you OK the first time a new version runs). I assume that that bit of information would be saved in the Registry.

[sub3R]

The ‘Name Not Found’ shouldn’t be a problem seeing they don’t worry the Windows Vista Notebook, & they appear there as well. I did a registry search on the WinXP PC for ‘Perl’ & it couldn’t be found, but I didn’t search for ‘getWizPnP’.

I don’t know why Process Monitor shows the Vista Notebook using ‘TCPCopy’ & ‘TCP Connect’ regularly when the WinXP PC doesn’t, unless it’s something to do with the Notebook’s wireless LAN connection or possibly Vista.

[prl]

...
I don’t know why Process Monitor shows the Vista Notebook using ‘TCPCopy’ & ‘TCP Connect’ regularly when the WinXP PC doesn’t, unless it’s something to do with the Notebook’s wireless LAN connection or possibly Vista.

Way out of my ken on Windows, but it could well be differences in the underlying Windows version (Vista vs XP).

[prl]

I've started to instrument my development copy of getWizPnP to try to work out why --check is occasionally returning missing data files on Windows XP when the files actually are there.

This is the additional error message info I get now:

Code: Select all

500 Can't connect to w.z.y.z:49152 (connect: timeout).

The message originates at the point where getWizPnP tries to make a TCP connection to the Beyonwiz to make a HTTP request. the actual IP address in w.x.y.z is the correct IP address for the Beyonwiz.

The only workaround for this may be to retry.

[sub3R]

...
The message originates at the point where getWizPnP tries to make a TCP connection to the Beyonwiz to make a HTTP request. the actual IP address in w.x.y.z is the correct IP address for the Beyonwiz.

I take it this is where it stalls (waits) at ~1min 30sec.
Just a guess, but I wonder if it’s the different ways WinXP & Vista (& Win7) handle TCP - just one example of a difference is mentioned here.
It would be easy to use all the ephemeral or temporary client ports in WinXP.

It would be interesting if a retry would work.

[IanSav]

Hi Peter,

I've started to instrument my development copy of getWizPnP to try to work out why --check is occasionally returning missing data files on Windows XP when the files actually are there.

This is the additional error message info I get now:

Code: Select all

500 Can't connect to w.z.y.z:49152 (connect: timeout).

The message originates at the point where getWizPnP tries to make a TCP connection to the Beyonwiz to make a HTTP request. the actual IP address in w.x.y.z is the correct IP address for the Beyonwiz.

The only workaround for this may be to retry.

Just a thought...

I wonder if you are making network connections to the Beyonwiz faster than it can process? If you don't like the retry idea then perhaps you can try introducing a small delay between connection attempts to give the Beyonwiz a chance to catch up.

Regards,
Ian.

[prl]

Hi Peter,

I've started to instrument my development copy of getWizPnP to try to work out why --check is occasionally returning missing data files on Windows XP when the files actually are there.

This is the additional error message info I get now:

Code: Select all

500 Can't connect to w.z.y.z:49152 (connect: timeout).

The message originates at the point where getWizPnP tries to make a TCP connection to the Beyonwiz to make a HTTP request. the actual IP address in w.x.y.z is the correct IP address for the Beyonwiz.

The only workaround for this may be to retry.

Just a thought...

I wonder if you are making network connections to the Beyonwiz faster than it can process? If you don't like the retry idea then perhaps you can try introducing a small delay between connection attempts to give the Beyonwiz a chance to catch up.

Regards,
Ian.

It's a possibility, but why only in XP? Why not in Win7, in Cygwin under Win7, in Linux or in OS X?

And doesn't TCP have retries with delay built into its connection protocol?

[sub3R]

... It would be easy to use all the ephemeral or temporary client ports in WinXP.

And this is the problem.

I suspected going by the number of client ports getwizpnp --check quickly used up (as shown in Process Explorer & Process Monitor) & the different client port number range WinXP was using compared to Vista, that the problem could be that the WinXP PC was using up all the client ephemeral ports (either that or the TCB static table filling up).

I decided to modify the registry to give a higher client ephemeral port upper limit in WinXP from the default of 1024-5000 to something higher (Vista uses 49152-65535, & I believe Win7 also). Looking in the registry there wasn’t a default setting shown so I followed an instruction for an early Windows server version (I couldn’t find anything specific for WinXP).

I entered the following in ‘start > run > regedit’ (the following is slightly different to the instruction):
Under ‘HKEY_LOCAL_MACHINE > SYSTEM > CurrentControlSet > Services > Tcpip > Parameters’; Right click on Parameters & select ‘New > DWORD value’. Under the Name column rename the new entry to ‘MaxUserPort’. Under the Type column the new entry should read ‘REG_DWORD’. Right click on ‘MaxUserPort’ & select ‘Modify’, in the opened ‘Edit DWORD Value’ window confirm ‘Value name:’ is ‘MaxUserPort’, select ‘Decimal’, enter 50,000 in ‘Value data:’ & click OK. Under the Data column the new entry should now show the Hex equivalent of 50,000 & 50,000 in brackets. Exit ‘regedit’ & reboot the PC.
Note: It is recommended to backup the registry before trying this – a mistake could cause major problems & once regedit is exited it automatically saves any changes.

Prior to changing this, getwizpnp --check stalls (waits) after checking 27 recordings at ~1min 40sec, waits for 3min, lists a missing data file & then continues checking.
After the above registry change it lists all the recordings without stalling (wait) & doesn’t show any missing data files.
I need to do a few more checks either way to confirm this 100%.

After this I’ll change the upper limit back to the default 5000 because I don’t know what ramifications a higher upper limit will have on an XP PC (I would be very happy to hear from any experts on this).

[IanSav]

Hi,

It looks like it is the Windows XP machine that needs the time to catch up.

Regards,
Ian.

[sub3R]

Yes, & I always thought XP was pretty good.

This article here explains more.

Peter, is it possible to explicitly request a specific port number as mentioned in the 2nd paragraph of that article (if that would work with what getwizpnp does) or is that too far down to change?

[prl]

Thanks, Dennis. That really sounds like you've cracked it. Do you know whether I can tweak the Win7 registry in the same way to reduce its number of ephemeral ports? And how do I back up the Registry?

I'm still not quite sure what to do about the ports, though. OS X appears to use the same port range as Win7 by default. I've tried limiting OS X to only use a 5000-port range, but it (very sensibly) just wraps around to the beginning of the range when it would go past the end.

I still need to try limiting the port range on Win7 to see if I can reproduce the problem there. Win7 is a much easier development environment for me to use than WinXP.

[prl]

Yes, & I always thought XP was pretty good.

This article here explains more.

Peter, is it possible to explicitly request a specific port number as mentioned in the 2nd paragraph of that article (if that would work with what getwizpnp does) or is that too far down to change?

OK, the article you've linked to was one I was just looking at (but I was concentrating on how to change the range using sysctl on OS X). The Windows section has a link to a port range "how-to" for Vista; I suspect the same may work for Win7.

Normal Unix system calls don't, IIRC, allow you to specify the local port when binding to a remote port. No idea about what the Windows stack capabilities are for this. The problem with using a fixed ephemeral port is that you need to put in increment-and-retry code if you try to use an ephemeral port number that someone else is already using.

[sub3R]

With an upper limit of 50,000 ports I consecutively ran getwizpnp --check on both S1s without any issues. Changing the upper port limit to 5000 I get the same stall condition on the same recording at the same time with a missing data file before I originally changed the registry – so this confirms the WinXP upper port limit default must be 5000 even though I couldn’t find it anywhere in the registry. It also confirms that WinXP hasn't kept pace with getWizPnP.exe.

... And how do I back up the Registry?

In my Windows tips notes I have written:
“Registry Backup from the Registry:
Run ‘regedit’ & expand the registry to the required spot that is to be backed up. On the ‘File’ menu click ‘Export’. In the ‘File name’ box type ‘backup of ......’ & then click ‘save’. This backs up this key - it can be restored by double-clicking this saved file.”

This link might make it clearer for a full registry backup of WinXP. Or a link for a full registry backup of Win7. There are also various official Microsoft versions but they are all basically the same. Note: I haven't tried restoring a partial or even a full registry backup.

... I've tried limiting OS X to only use a 5000-port range, but it (very sensibly) just wraps around to the beginning of the range when it would go past the end.

That makes good sense. I think I read somewhere that in XP or earlier versions the previously used ports aren’t made available again for a certain period of time (I could be wrong but I think it was something like 4 minutes! – which is probably why I got these errors here).

I’ll see if I can find something specific to Win7.

There is a way to fix all this in WinXP, just make a comment in the release notes that --check doesn’t work 100% correctly with a standard WinXP operating system.

[prl]

...
OK, the article you've linked to was one I was just looking at (but I was concentrating on how to change the range using sysctl on OS X). The Windows section has a link to a port range "how-to" for Vista; I suspect the same may work for Win7.
....

This article applies to a different operating system than the one you are using. Article content that may not be relevant to you is disabled.

Fortunately, it does show something that I think might well work.

[prl]

There is a mechanism in the Perl LWP (HTTP interface) packages to keep the same connection (and port) open for multiple requests, but the HTTP server on the Beyonwiz doesn't support it

[sub3R]

This article applies to a different operating system than the one you are using. Article content that may not be relevant to you is disabled.

Yes, I came across that comment a few times.

This topic looks like it includes Win7. Microsoft Support forgot to mention to reboot the PC after this change though. That is the article I followed.

More interesting reading on Vista/Win7 ports here – look under TcpTimedWaitDelay (port allocation) near the end of the article. Not relevant to WinXP but it looks like the time to wait before ephemeral ports can be reclaimed for use (TcpTimedWaitDelay) is 120sec in Vista (& probably Win7) but can be reduced to 30sec recommended. It also gives a bit more info on ‘MaxUserPort’.
The ‘netsh’ commands may work in Win7 - I couldn’t get ‘netsh int ipv4 show dynamicportrange tcp’ to work on the WinXP PC (‘int’ isn’t a valid command according to help).

[sub3R]

I didn't see your last post.

There is a mechanism in the Perl LWP (HTTP interface) packages to keep the same connection (and port) open for multiple requests, but the HTTP server on the Beyonwiz doesn't support it

That sounds like it could have been the solution.

[prl]

...
More interesting reading on Vista/Win7 ports here – look under TcpTimedWaitDelay (port allocation) near the end of the article. Not relevant to WinXP but it looks like the time to wait before ephemeral ports can be reclaimed for use (TcpTimedWaitDelay) is 120sec in Vista (& probably Win7) but can be reduced to 30sec recommended. It also gives a bit more info on ‘MaxUserPort’.
The ‘netsh’ commands may work in Win7 - I couldn’t get ‘netsh int ipv4 show dynamicportrange tcp’ to work on the WinXP PC (‘int’ isn’t a valid command according to help).

This sounds like why the check continues without a problem after the connection failure - the connection timeout is 3 minutes, so by the time it finishes, the ports that previously couldn't be used become available. That means the problem could be worked around by using retries, but the retries would have to wait about the 2 min (at least) for the port timeout, otherwise (if I used a much shorted timeout) the retry would fail.

[peteru]

I read somewhere that in XP or earlier versions the previously used ports aren’t made available again for a certain period of time

That's part of the TCP spec. Host/port pairs stay in TIME_WAIT for 2MSL. You can see those with netstat:

Code: Select all

$ netstat -tan
Proto Recv-Q Send-Q Local Address          Foreign Address    State      
...
tcp        0      0 192.168.x.y:51219      192.168.x.z:80     TIME_WAIT  
tcp        0      0 192.168.x.y:49695      192.168.x.z:80     ESTABLISHED
tcp        0      0 192.168.x.y:51225      192.168.x.z:80     TIME_WAIT
...

First and third connections to the server have been closed and are in TIME_WAIT (2MSL on my system is 60 seconds), the second connection is still active. You may want to read the manpage for setsockopt, but beware that the semantics differ subtly between Winsock, Linux and *BSD systems. Good luck with this!

[prl]

Thanks, Peter. I've had a look at (OS X) setsockopt(2), and I can't find anything that looks helpful.

My current inclination is to do the request with a shorter timeout (10-20 sec) than the default (180 sec), and to allow perhaps 150 secs worth of retries (say 10 retries @ 15 sec). This doesn't have the same semantics as the normal timeout, but given that this is all LAN traffic and long package transit times aren't expected, I don't think it would matter much.

[sub3R]

... You can see those with netstat:

Thanks, I didn’t have much success with netstat when I tried it a while ago on this problem, but ’netstat -n 5’ shows how quickly the ephemeral ports gets used up with getwizpnp --check & what happens when they do.

The following is taken from this Microsoft Support article. Seeing that I don’t appear to have IPv6 the default must be 120 seconds, not 4 minutes as I thought for WinXP.

“TcpTimedWaitDelay
Key: Tcpip\Parameters
Value Type: REG_DWORD - Time in seconds
Valid Range: 30-300 (decimal)
Default: 0x78 (120 decimal)
Description: This parameter determines the time that a connection stays in the TIME_WAIT state when it is closing. As long as a connection is in the TIME_WAIT state, the socket pair cannot be re-used. This is also known as the "2MSL" state. According to RFC793, the value should be two times the maximum segment lifetime on the network. See RFC793 for more information.
Note: In Microsoft Windows 2000, the default value is 240 seconds. For Windows XP and Microsoft Windows Server 2003, the default was changed to 120 seconds for the IPv4 stack to increase performance. The default value for the IPv6 stack is 240 seconds.”

Another view on the subject here.

[prl]

I'd rather not mess about with the TIMED_WAIT timeout on a system-wide basis, or suggest changing it to users of getWizPnP. Especially not to users who use getWizPnP via YARDWiz or WizZilla.

I've coded my idea for doing shorter timeouts+retries. Still to test it on WinXP. But I'm also not all that happy about the way --check consumes ports on WinXP, though.

IMO, the underlying problem here is that the Beyonwiz HTTP server is supposed to be HTTP 1.1, but doesn't do this: "HTTP implementations SHOULD implement persistent connections".

[sub3R]

I totally agree about the registry change, in fact I wouldn't recommend anyone to make any changes to the registry unless they really know what they are doing & understand what risks they are taking. The changes I’ve made have been for testing only.

More here: I just made a ‘TcpTimedWaitDelay’ entry in the registry & set the timeout to 120sec to confirm the default timeout was 120sec on my XP PC (there wasn’t a ‘TcpTimedWaitDelay’ entry in the registry prior to this).

I then set the timeout to 60sec & ran a getwizpnp --check consecutively on both S1s - they both ran through without stalling or listing any missing data files.
Both the above 120sec & 60sec tests were carried out with ‘MaxUserPort’ back to the default of 5000 (5000 -1024 = 3976 available ephemeral ports).

[IanB]

When you are exhausting all the ephemeral ports you might retry the failing bind with the SO_REUSEADDR option. You may need to manually select your source port numbers rather than auto select it with zero.

Alternatively you might use setsockopt() with the SO_DONTLINGER option on your ephemeral sockets. This will hard reset the socket on close and avoid the TIME_WAIT delay phase.

[prl]

When you are exhausting all the ephemeral ports you might retry the failing bind with the SO_REUSEADDR option. You may need to manually select your source port numbers rather than auto select it with zero.

Alternatively you might use setsockopt() with the SO_DONTLINGER option on your ephemeral sockets. This will hard reset the socket on close and avoid the TIME_WAIT delay phase.

Hm, that's not how I read the function of SO_DONTLINGER. In the past, I've had mixed success in the past with SO_REUSEADDR (perhaps because I don't really understand what it's intended to do).

Anyway, I can't use any of this without reaching deep into LWP::Protocol::http and messing with an intended-to-be-internal function. This means, amongst other things, having to worry about internal interfaces inside LWP.

I'm now inclining to a scheme to limit the number of ports in WAIT state by keeping track of how many ports have been used in the past 120 or so seconds, and keeping that below some number considerably less that the 3976 allowed by XP. It can be relatively simply implemented with a timestamp queue for HTTP requests, and sleeping while there are more that the given number of WAIT state ports in the queue. THe sleep can even be calculated from the current time and the timestamp in the oldest queue element, so polling should not be necessary.

Oddly enough, on OS X netstat doesn't show any ports in any wait state other that being transitorially in FINAL_WAIT_1. I haven't given any other OSs the netstat treatment yet.

[sub3R]

... and keeping that below some number considerably less that the 5000 allowed by XP.

Probably a typo but I think you mean the 3976 allowed by XP (the default range in XP is from 1024 to 5000).

I have seen FINAL_WAIT_1 crop up very rarely in ‘netstat -n 2’ but it is usually TIME_WAIT & eventually ESTABLISHED.

[prl]

... and keeping that below some number considerably less that the 5000 allowed by XP.

Probably a typo but I think you mean the 3976 allowed by XP (the default range in XP is from 1024 to 5000).

More not remembering what you'd written about the limits than a typo. Fixed now.

I have seen FINAL_WAIT_1 crop up very rarely in ‘netstat -n 2’ but it is usually TIME_WAIT & eventually ESTABLISHED.

On a single port, ESTABLISHED, then TIME_WAIT. ESTABLISHED is the state of normal operation; TIME_WAIT is a state in connection shutdown. I think FINAL_WAIT_1 is a transitory state in connection shutdown.

[peteru]

So you will be rate limiting the application on all platforms to cope with the shortcomings of the lowest common denominator? If so, should you be also taking into account DOS limits?

Perhaps you should have a command line options to "enable rate limiting" with number of connections and connection lifetime settings. I would default to unlimited on all platforms, except XP, if you can detect XP at runtime. If you do decide to rate limit by default, it may be a good idea to print a warning/notice when the rate limiting kicks in and suggest to the user what options they can tweak.

[sub3R]

Some good points there considering that getwizpnp --check takes a long time to check a wiz containing a lot of recordings. On a WinXP PC with just TcpTimedWaitDelay changed from 120sec to 60sec so a port is always available it takes almost 4 1/2 minutes to complete the check over an Ethernet LAN with 343,408MB of recordings on the wiz's drive.
On YARDWiz it appears even slower because there isn’t any feedback.

[sub3R]

... I haven't given any other OSs the netstat treatment yet.

If you want to try something different to netstat on Windows, give TCPView a try - available for download here. I find it easier to see what’s going on but it would be nice if it had time stamping.

Sysinternals has a lot of handy downloads including Process Explorer & Process Monitor (as you would know Luke suggests PsKill from that site to stop, pause or shut down YARDWiz in Windows under certain conditions - it works well too).

[prl]

So you will be rate limiting the application on all platforms to cope with the shortcomings of the lowest common denominator? If so, should you be also taking into account DOS limits?
...

I was intending to use

Code: Select all

if($^O eq 'MSWin32')

to set the limits. And possibly larger limits, or unlimited, on more forgiving systems. I need to check whether I can differentiate WinXP from Win7 and other more modern systems.

I've never thought about supporting getWizPnP on DOS.

[peteru]

Perhaps POSIX::uname() will give you more detail. Alternative solution may be $Config{osname} and $Config{osver}.

[peteru]

On a second read, perhaps $Config and $^O are not the right way to go, since they appear to hold configure/build values, rather than execution environment values.