mach2000 Posted August 6, 2015 Report Posted August 6, 2015 I'm having an issue with my WideFS connection getting corrupted on flights over 5 hours. I run RC4 via WideFS on a remote computer and everything works perfectly... except on long flights. Once I hit about the 5 hour mark, I get a message on my ShowText app that the 'IPC Request Contains Bad Data'. It then displays 'Re-establish Link'... 'Link Established' (and the process then repeats over and over). Interestingly, RC4's "next waypoint" line continues to show my next waypoint but the distance to go varies between the correct mileage and several thousand miles in the wrong direction (so the data definitely appears to be getting corrupted). Once this happens, Radar Contact gets confused and tells me to get back on course, to slow down, to get better pilot skills, etc. Shutting down WideFS does not resolve the problem and I'm forced to fly without ATC for the remainder of the flight. This problem is repeatable regardless of the route... but as I said before, I need to fly for 5 hours (real-time) for it to occur. I've checked my logs and don't see anything out of the ordinary. All my simconnect apps (ASN, Aivla EFB, etc.) continue to run without interruption. Any ideas?
mach2000 Posted August 6, 2015 Author Report Posted August 6, 2015 For reference, here are my log files. (Note that I paused the sim several times to load some amended flightplans when I was forced to revert to the default ATC... the stoppages occurred after the IPC data became corrupted). Wideclient.log: ********* WideClient Log [version 6.999n] Class=FS98MAIN *********Date (dmy): 05/08/15, Time 11:32:21.371: Client name is SPEEDY 94 LUA: "D:\FS Utilities\WideFS\Initial.LUA": not found 109 Attempting to connect now 109 Trying to locate server: Need details from Server Broadcast 109 Failed to connect: waiting to try again 2168 Attempting to connect now 4228 Server = ZIPPY 4228 Trying TCP/IP host "ZIPPY" port 8002 ... 4228 ... Okay, IP Address = 192.168.0.132 4228 Connection made okay! 381641 New Client Application: "rcv4" (Id=4188) 389363 New Client Application: "ShowText" (Id=2228) 35640347 Error on client post-Connection Select() [Error=10053] Software caused connection abort 35640347 Connection closed by server! 35640347 The connection was terminated due to a time-out or other failure! 35640363 Attempting to connect now 35640363 Server = ZIPPY 35640410 Trying TCP/IP host "ZIPPY" port 8002 ... 35640410 ... Okay, IP Address = 192.168.0.132 35661439 Error on client pre-Connection Select() [Error=10060] Connection timed out 35661439 Ready to try connection again 35663467 Attempting to connect now 35663467 Giving up server, looking for another! 35663467 Server = ZIPPY 35663467 Trying TCP/IP host "ZIPPY" port 8002 ... 35663467 ... Okay, IP Address = 192.168.0.132 35678692 ****** End of session performance summary ****** 35678692 Total time connected = 35637 seconds 35678692 Reception maximum: 30 frames/sec, 3260 bytes/sec 35678692 Reception average whilst connected: 28 frames/sec, 49 bytes/sec 35678692 Transmission maximum: 22 frames/sec, 9596 bytes/sec 35678692 Transmission average whilst connected: 0 frames/sec, 33 bytes/sec 35678692 Max receive buffer = 2228, Max send depth = 13, Send frames lost = 0 35678692 **************** Individual client application activity **************** 35678692 Client 4188 requests: 8550337 (Ave 239/sec), Data: 1114856286 bytes (31283/sec), Average 130 bytes/Process 35678692 Client 2228 requests: 48830 (Ave 1/sec), Data: 7029270 bytes (197/sec), Average 143 bytes/Process 35678692 ********* Log file closed (Buffers: MaxUsed 14, Alloc 9899913 Freed 9899904 Refused 0) ********* FSUIPC4.log: ********* FSUIPC4, Version 4.938b by Pete Dowson *********Reading options from "C:\FSX\Modules\FSUIPC4.ini"Running inside FSX on Windows 7Module base=628B0000User Name="Marc Schrier"User Addr=xxxxxxx@xxxxxxxFSUIPC4 Key is providedWideFS7 Key is provided 16 System time = 05/08/2015 11:20:10 16 FLT UNC path = "\\ZIPPY\Documents\Flight Simulator X Files\" 827 Trying to connect to SimConnect Acc/SP2 Oct07 ... 842 FS UNC path = "\\ZIPPY\FSX\" 983 LogOptions=00000000 00000001 983 SIM1 Frictions access gained 983 Wind smoothing fix is fully installed 983 G3D.DLL fix attempt installed ok 983 SimConnect_Open succeeded: waiting to check version okay 983 Trying to use SimConnect Acc/SP2 Oct07 11201 Running in "Microsoft Flight Simulator X", Version: 10.0.61637.0 (SimConnect: 10.0.61259.0) 11201 Initialising SimConnect data requests now 11201 FSUIPC Menu entry added 11232 \\ZIPPY\Documents\Flight Simulator X Files\Custom Startup.FLT 11232 \\ZIPPY\FSX\SimObjects\Airplanes\C172\Cessna172SP.AIR 44944 \\ZIPPY\FSX\SimObjects\Airplanes\PMDG 777-200LR\B777-200LR.AIR 204018 D:\Documents\Flight Simulator X Files\RPLLOMDB01.PLN 279507 System time = 05/08/2015 11:24:50, Simulator time = 23:25:23 (15:25Z) 279507 Aircraft="PMDG 777-21HLR Emirates" 279569 Starting everything now ... 280646 Weather Mode now = Theme 280693 Advanced Weather Interface Enabled 281254 ASN active function link set 281254 Ready for ASN WX radar 1112193 FSUIPC Display Title set = "Radar Contact" 2670160 D:\Documents\Flight Simulator X Files\WX.PLN 2721266 D:\Documents\Flight Simulator X Files\WX.PLN 2721266 D:\Documents\Flight Simulator X Files\WX.PLN 5916541 D:\Documents\Flight Simulator X Files\WX.PLN 6003496 D:\Documents\Flight Simulator X Files\WX.PLN 6303735 D:\Documents\Flight Simulator X Files\WX.PLN 6471124 D:\Documents\Flight Simulator X Files\WX.PLN 6906211 D:\Documents\Flight Simulator X Files\WX.PLN 8377893 D:\Documents\Flight Simulator X Files\WX.PLN 8502678 D:\Documents\Flight Simulator X Files\WX.PLN 8802778 D:\Documents\Flight Simulator X Files\WX.PLN 9389778 D:\Documents\Flight Simulator X Files\WX.PLN 10330776 D:\Documents\Flight Simulator X Files\WX.PLN 11058256 D:\Documents\Flight Simulator X Files\WX.PLN 11182698 D:\Documents\Flight Simulator X Files\WX.PLN 11435809 D:\Documents\Flight Simulator X Files\WX.PLN 11735955 D:\Documents\Flight Simulator X Files\WX.PLN 12027646 D:\Documents\Flight Simulator X Files\WX.PLN 12862002 D:\Documents\Flight Simulator X Files\WX.PLN 13162132 D:\Documents\Flight Simulator X Files\WX.PLN 13346400 D:\Documents\Flight Simulator X Files\WX.PLN 13646499 D:\Documents\Flight Simulator X Files\WX.PLN 13715140 D:\Documents\Flight Simulator X Files\WX.PLN 14015239 D:\Documents\Flight Simulator X Files\WX.PLN 14255964 D:\Documents\Flight Simulator X Files\WX.PLN 14556063 D:\Documents\Flight Simulator X Files\WX.PLN 14856178 D:\Documents\Flight Simulator X Files\WX.PLN 14936862 D:\Documents\Flight Simulator X Files\WX.PLN 15236992 D:\Documents\Flight Simulator X Files\WX.PLN 15557293 D:\Documents\Flight Simulator X Files\WX.PLN 15857377 D:\Documents\Flight Simulator X Files\WX.PLN 16157460 D:\Documents\Flight Simulator X Files\WX.PLN 16457544 D:\Documents\Flight Simulator X Files\WX.PLN 16757643 D:\Documents\Flight Simulator X Files\WX.PLN 17057680 D:\Documents\Flight Simulator X Files\WX.PLN 17634400 D:\Documents\Flight Simulator X Files\WX.PLN 18197049 D:\Documents\Flight Simulator X Files\WX.PLN 18956805 D:\Documents\Flight Simulator X Files\WX.PLN 19256935 D:\Documents\Flight Simulator X Files\WX.PLN 19557065 D:\Documents\Flight Simulator X Files\WX.PLN 20189618 D:\Documents\Flight Simulator X Files\WX.PLN 20633191 D:\Documents\Flight Simulator X Files\WX.PLN 21191675 D:\Documents\Flight Simulator X Files\WX.PLN 21333043 Sim stopped: average frame rate for last 21055 secs = 29.1 fps 21466361 D:\Documents\Flight Simulator X Files\WX.PLN 21637370 Sim stopped: average frame rate for last 299 secs = 29.6 fps 21970853 D:\Documents\Flight Simulator X Files\WX.PLN 22402835 Sim stopped: average frame rate for last 551 secs = 29.7 fps 22431056 D:\Documents\Flight Simulator X Files\RPLLOMDB01.PLN 22472989 Sim stopped: average frame rate for last 41 secs = 29.3 fps 22530959 D:\Documents\Flight Simulator X Files\WX.PLN 22580349 Sim stopped: average frame rate for last 92 secs = 29.4 fps 22868452 D:\Documents\Flight Simulator X Files\WX.PLN 23335940 D:\Documents\Flight Simulator X Files\WX.PLN 23636023 D:\Documents\Flight Simulator X Files\WX.PLN 24132871 D:\Documents\Flight Simulator X Files\WX.PLN 24628658 D:\Documents\Flight Simulator X Files\WX.PLN 24789230 D:\Documents\Flight Simulator X Files\WX.PLN 25089298 D:\Documents\Flight Simulator X Files\WX.PLN 25207874 D:\Documents\Flight Simulator X Files\WX.PLN 25507973 D:\Documents\Flight Simulator X Files\WX.PLN 25850177 D:\Documents\Flight Simulator X Files\WX.PLN 26150245 D:\Documents\Flight Simulator X Files\WX.PLN 26402311 D:\Documents\Flight Simulator X Files\WX.PLN 26702395 D:\Documents\Flight Simulator X Files\WX.PLN 27002431 D:\Documents\Flight Simulator X Files\WX.PLN 27252298 D:\Documents\Flight Simulator X Files\WX.PLN 27552397 D:\Documents\Flight Simulator X Files\WX.PLN 27852668 D:\Documents\Flight Simulator X Files\WX.PLN 28452835 D:\Documents\Flight Simulator X Files\WX.PLN 29038291 D:\Documents\Flight Simulator X Files\WX.PLN 29338312 D:\Documents\Flight Simulator X Files\WX.PLN 29638411 D:\Documents\Flight Simulator X Files\WX.PLN 29681218 D:\Documents\Flight Simulator X Files\WX.PLN 29755131 Sim stopped: average frame rate for last 7137 secs = 29.6 fps 29771153 D:\Documents\Flight Simulator X Files\RPLLOMDB01.PLN 29997526 D:\Documents\Flight Simulator X Files\WX.PLN 30297547 D:\Documents\Flight Simulator X Files\WX.PLN 30597662 D:\Documents\Flight Simulator X Files\WX.PLN 30766891 D:\Documents\Flight Simulator X Files\WX.PLN 30983234 D:\Documents\Flight Simulator X Files\WX.PLN 31283302 D:\Documents\Flight Simulator X Files\WX.PLN 31396418 Sim stopped: average frame rate for last 1625 secs = 29.7 fps 31433047 D:\Documents\Flight Simulator X Files\RPLLOMDB01.PLN 31620248 D:\Documents\Flight Simulator X Files\WX.PLN 31949738 D:\Documents\Flight Simulator X Files\WX.PLN 32092136 D:\Documents\Flight Simulator X Files\WX.PLN 32392219 D:\Documents\Flight Simulator X Files\WX.PLN 32692568 D:\Documents\Flight Simulator X Files\WX.PLN 32927599 D:\Documents\Flight Simulator X Files\WX.PLN 33108856 D:\Documents\Flight Simulator X Files\WX.PLN 33145267 D:\Documents\Flight Simulator X Files\WX.PLN 33177247 D:\Documents\Flight Simulator X Files\WX.PLN 33211318 D:\Documents\Flight Simulator X Files\WX.PLN 33366445 D:\Documents\Flight Simulator X Files\WX.PLN 33472354 D:\Documents\Flight Simulator X Files\WX.PLN 33675093 D:\Documents\Flight Simulator X Files\WX.PLN 33834199 D:\Documents\Flight Simulator X Files\WX.PLN 34215512 D:\Documents\Flight Simulator X Files\WX.PLN 34360531 D:\Documents\Flight Simulator X Files\WX.PLN 36336174 Sim stopped: average frame rate for last 4903 secs = 27.2 fps
Pete Dowson Posted August 6, 2015 Report Posted August 6, 2015 There are no errors detected by WideClient. over a period of nearly 10 hours! Total time connected = 35637 seconds You fly in real time for 10 hours? Phew! Not sure why you bothered showing the FSUIPC log, which has nothing to do with the networking part. The WideServer log is relevant, of course, but you don't show that. It sounds like something in the client application's process is getting corrupted, or there are memory problems on the client PC. Certainly nothing looks amiss on the WideFS side. BTW the currently supported version of FSUIPC is 4.942. Yours is out of date. Pete
mach2000 Posted August 7, 2015 Author Report Posted August 7, 2015 There are no errors detected by WideClient. over a period of nearly 10 hours! Total time connected = 35637 seconds You fly in real time for 10 hours? Phew! Lol... for the long-hauls, my OCD kicks in and I insist on doing it real-time... I don't do it too often (especially since it creates the aforementioned problems with WideFS/RC). I'll need to do another long flight to provide a Wideserver log (the relevant one got overwritten). Do you recommend that I change the logging options to try to get to the root of the problem? On a 5+ hour flight, I'm extremely hesitant. I know that I can change the logging criteria in wideclient (after enabling Log=K1190 in the ini)... so I can use Shift+> to get full logging after the problem appears. Does that sound prudent? Is there a similar hotkey logging option in WideServer (I didn't see it in the documentation)? One thing to add...the problem is not unique to Radar Contact -- if I use ProFlight Emulator for ATC (again running on WideFS), the same issue occurs.
Pete Dowson Posted August 7, 2015 Report Posted August 7, 2015 Lol... for the long-hauls, my OCD kicks in and I insist on doing it real-time... I don't do it too often (especially since it creates the aforementioned problems with WideFS/RC). I'll need to do another long flight to provide a Wideserver log (the relevant one got overwritten). Do you recommend that I change the logging options to try to get to the root of the problem? On a 5+ hour flight, I'm extremely hesitant. I know that I can change the logging criteria in wideclient (after enabling Log=K1190 in the ini)... so I can use Shift+> to get full logging after the problem appears. Does that sound prudent? Is there a similar hotkey logging option in WideServer (I didn't see it in the documentation)? One thing to add...the problem is not unique to Radar Contact -- if I use ProFlight Emulator for ATC (again running on WideFS), the same issue occurs. I'm not sure what to advise at present. It sounds as if the TCP/IP buffers on the Client are filling up and not being freed. Those are a function of the Windows network drivers. Could you try UDP protocol, to see if it makes a difference? It's only problem, used with something like Radar Contact, is that the sequence of data packets can get out of order, and any bad packets will simply be discarded. However, anything serious in that should be reported in the log, even without extra loogging. Pete
mach2000 Posted August 9, 2015 Author Report Posted August 9, 2015 I tried a couple of flights using UDP protocol this weekend... same result. Actually, when using UDP, RC4 generates an error: Run-time error "6": RadarContact.fsuipc.rcv4code . This still occurs about 5-6 hours into the flight. While it's easy to blame RC4's 10-year old code for this (which is what I did initially), the fact that PFE has similar issues is what makes me believe it may be a WideFS problem. Here are the logs (not much to see): WideServer: ********* WideServer.DLL Log [version 7.938b] *********Blocksize guide = 8192 (double allowed)Date (dmy): 09/08/15, Time 01:43:48.854: Server name is ZIPPY 15772 Initialising TCP/IP server 15772 Initialising UDP/IP server 16099 Broadcasting service every 1000 mSecs 16099 Preferred protocol = UDP 34976 Connected to computer "SPEEDY" running WideClient version 6.999 (IP=192.168.0.133) UDP 30275801 Restarting service due to zero reception! 30477884 Closing down now ...Memory managed: Offset records: 20005 alloc, 20003 freeRead buffer usage: 21973 alloc, 21973 free, max in session: 1Write buffer usage: 1794136 alloc, 1794136 free, max in session: 1Throughput maximum achieved: 30 frames/sec, 4002 bytes/secThroughput average achieved for complete session: 14 frames/sec, 1142 bytes/secAverage receive rate from "SPEEDY": 0 frames/sec, 38 bytes/sec********* Log file closed ********* WideClient: ********* WideClient Log [version 6.999n] Class=FS98MAIN *********Date (dmy): 09/08/15, Time 01:44:19.583: Client name is SPEEDY 78 LUA: "D:\FS Utilities\WideFS\Initial.LUA": not found 94 Attempting to connect now 94 Trying to locate server: Need details from Server Broadcast 94 Failed to connect: waiting to try again 2153 Attempting to connect now 4212 Server = ZIPPY 4228 Trying UDP/IP host "ZIPPY" port 8002 ... 4228 ... Okay, IP Address = 192.168.0.132 4228 UDP connectionless mode set up okay! 4493 Connection made: receiving okay! 127344 New Client Application: "rcv4" (Id=3240) 133116 New Client Application: "ShowText" (Id=3100) 30235630 ****** End of session performance summary ****** 30235630 Total time connected = 30231 seconds 30235630 Reception maximum: 30 frames/sec, 3989 bytes/sec 30235630 Reception average whilst connected: 29 frames/sec, 30 bytes/sec 30235630 Transmission maximum: 17 frames/sec, 9447 bytes/sec 30235630 Transmission average whilst connected: 0 frames/sec, 39 bytes/sec 30235630 Max receive buffer = 4608, Max send depth = 13, Send frames lost = 0 30235630 **************** Individual client application activity **************** 30235646 Client 3240 requests: 8304669 (Ave 274/sec), Data: 931163112 bytes (30801/sec), Average 112 bytes/Process 30235646 Client 3100 requests: 58821 (Ave 1/sec), Data: 8369784 bytes (276/sec), Average 142 bytes/Process 30235646 ********* Log file closed (Buffers: MaxUsed 14, Alloc 9492238 Freed 9492211 Refused 0) *********
Pete Dowson Posted August 9, 2015 Report Posted August 9, 2015 I tried a couple of flights using UDP protocol this weekend... same result. Actually, when using UDP, RC4 generates an error: Run-time error "6": RadarContact.fsuipc.rcv4code . This still occurs about 5-6 hours into the flight. While it's easy to blame RC4's 10-year old code for this (which is what I did initially), the fact that PFE has similar issues is what makes me believe it may be a WideFS problem. There's nothing in WideFS itself that is going to change after so long a period. I think it must be a Networking problem, but it will be lower down, in the Windows drivers or hardware. Both WideClient and WideServer always log any actual errors which are reported back to it by the Network, and none have occurred. They also log errors like missing frames (they are sequence numbered), so your UDP protocol is also behaving well, not getting frames out of order (else they'd be logged). I really don't know what to suggest. Does the WideClient displayed frame rate deteriorate over time (you can display it in its title bar)? If so maybe it is just that the client programs aren't getting the feed they need in the time they need it in. However, your logged performance data looks reasonable: Server: Throughput maximum achieved: 30 frames/sec, 4002 bytes/sec Throughput average achieved for complete session: 14 frames/sec, 1142 bytes/sec Average receive rate from "SPEEDY": 0 frames/sec, 38 bytes/sec Client: 30235630 Reception maximum: 30 frames/sec, 3989 bytes/sec 30235630 Reception average whilst connected: 29 frames/sec, 30 bytes/sec 30235630 Transmission maximum: 17 frames/sec, 9447 bytes/sec 30235630 Transmission average whilst connected: 0 frames/sec, 39 bytes/sec 30235630 Max receive buffer = 4608, Max send depth = 13, Send frames lost = 0 30235630 **************** Individual client application activity **************** 30235646 Client 3240 requests: 8304669 (Ave 274/sec), Data: 931163112 bytes (30801/sec), Average 112 bytes/Process 30235646 Client 3100 requests: 58821 (Ave 1/sec), Data: 8369784 bytes (276/sec), Average 142 bytes/Process RCV4's requests appear to be sent at good regular intervals: 30235646 Client 3240 requests: 8304669 (Ave 274/sec), Data: 931163112 bytes (30801/sec), Average 112 bytes/Process though the difference between maximum and average transmission rate is quite marked. Maybe the send buffers in the Client are getting clogged (I mean, here, the Windows driver or hardware driver buffers): 30235630 Transmission maximum: 17 frames/sec, 9447 bytes/sec 30235630 Transmission average whilst connected: 0 frames/sec, 39 bytes/sec which of course agrees with what the Server saw: Average receive rate from "SPEEDY": 0 frames/sec, 38 bytes/sec I really do not know what to suggest. Perhaps see if there are new drivers for the networking part of your systems? I'm not going to be changing any of the Networking code in WideFS, which hasn't been touched now for about 15 years (it still supports IPX/SPX which was the best protocol ever for local networks!) and has been successful all that time without tinkering. I'd probably do more damage than good if I did try to mess with it. Maybe there are some Network analysis tools which can help get to the bottom of this? Pete
Pete Dowson Posted August 10, 2015 Report Posted August 10, 2015 There's one thing I'd like you to try, to see if it helps at all. Next time it happens, or you think it is impending, go to FSUIPC's options and on the first tab disable WideFS. OK out,wait a while (till WideClient says waiting for a connection), then go back in and re-enable WideFS.. Hopefully WideClient will still be trying to reconnect and will then do so. This might cause the underlying network driver stuff to release it's buffers and start over. If it does help, it might be worth me adding a KEYSEND parameter to the Client's armoury to force it to reconnect on instruction from the Server, which could then be triggered by keypress or button. I really can't think of anything else. I have an 8-PC network here, of which 4 are usually kept pretty busy most of the day (running cockpit displays and scanning all the switches and dials). I don't like long flights, so things like Radar Contact are only running for an hour or two at a time, but we do fly two or three flights without reloading anything else sometimes. Not often, though. I find FS itself runs far better if it is restarted between flights. Pete
mach2000 Posted August 10, 2015 Author Report Posted August 10, 2015 Thanks Pete. I'll give it a try... though I have a bad feeling that RC4 may not be cooperative. I already tried something similar by assigning a hotkey to restart wideserver - but the restart froze RC4 (and my framerate/VAS script on wideclient if I remember correctly)... but that was a while back and my memory is not what it used to be. I'll give it a shot and report back (may be a couple of days as I have family obligations this evening). I may be showing my networking ignorance here, but I'm thinking the reason for the difference between maximum and average transmissions is that RC4 doesn't usually have much of reason to send anything to FSX. I imagine it sends most of its data at initialization and then goes into "monitor mode" sending only a handful of instructions (menu changes, ai aircraft freezes, etc.) for the remainder of the session. If anything is clogging up the buffers, I would think it is ActiveSky Next via Simconnect (although it has never given me any obvious problems). I'm tempted to try a flight without ASN and see if the problem persists... but that's a tall order because I really can't live without ASN at this point :).
Pete Dowson Posted August 10, 2015 Report Posted August 10, 2015 Thanks Pete. I'll give it a try... though I have a bad feeling that RC4 may not be cooperative. I already tried something similar by assigning a hotkey to restart wideserver Er, how would you restart the Server without closing FS and restarting it, or doing what I just suggested, which isn't possible with a hotkey -- well at least I don't think it is! If anything is clogging up the buffers, I would think it is ActiveSky Next via Simconnect (although it has never given me any obvious problems). I'm tempted to try a flight without ASN and see if the problem persists... but that's a tall order because I really can't live without ASN at this point I run ASN quite happily on the same PC as FSX. Doesn't seem to present any pronlems. I don't have many other programs on there -- Aivlasoft's EFB server, OpusFSI's server (used only for the views, instead of EZDOK), and Prosim's MCP. None of them impinge on FSX noticeably, but of course they won't be tying up the network at all. Pete
mach2000 Posted August 11, 2015 Author Report Posted August 11, 2015 Er, how would you restart the Server without closing FS and restarting it, or doing what I just suggested, which isn't possible with a hotkey -- well at least I don't think it is! ** Biting Tongue :rolleyes: ** From the WideFS Technical Document: The [user] Section (… but still the [WideServer] section on FSX) RestartHotKey=: This option allows you to define a hot key which you can use in Flight Simulator to force WideServer automatically close down its network serving action and restart it (just as if it had been freshly loaded). If you have problems on your LAN with WideFS clients apparently stalling then this may help unclog Windows‘ sockets software (?). The format for specifying the hot Key is ‗keycode,shift states‘, for example: RestartHotKey=78,11 specifies Shift+Ctrl+N (N for "Network"). The first value determines the main key required. This is a Windows ‗virtual keycode‘—a list of these is shown in an Appendix to this document. The second value determines additional shift states needed, as follows omitted or 8 key on its own 9 Shift + 10 Control + 11 Shift + Control + 12 Alt + 13 Shift + Alt + 14 Control + Alt + 15 Shift + Control + Alt + Note, however, that not all combinations will work with all keycodes. The values can also be 0–7 instead of 8–15. The addition of '8' here is merely to provide compatibility with the way key presses are specified in Fligfht Simulator‘s CFG files. And especially note that the use of the ‗Alt‘ key in many combinations is problematic and will tend to invoke FS‘s menus. Avoid this key if at all possible. I'll give it a try without ASN later this week and see if it makes any difference. If it helps, I'll experiment with running different programs on my FSX machine... may even move RC4 over there. Will keep you advised.
mach2000 Posted August 11, 2015 Author Report Posted August 11, 2015 Did a couple short tests before bed this evening. Confirmed that RC4 recovers when manually disabling/re-enabling WideFS via FSUIPC as suggested. Oddly enough, the hotkey restart still freezes RC4... so won't be using that "function" anymore. Will set up a flight tomorrow night, let it run while I'm asleep, and try the refresh when I wake up (will need to go back to TCP/IP to keep RC4 from generating an error). We'll see what happens (fingers crossed).
Pete Dowson Posted August 11, 2015 Report Posted August 11, 2015 RestartHotKey=: This option allows you to define a hot key which you can use in Flight Simulator to force WideServer automatically close down its network serving action and restart it (just as if it had been freshly loaded). If you have problems on your LAN with WideFS clients apparently stalling then this may help unclog Windows‘ sockets software (?). Hey, that's a good idea! I had completely forgotten I'd had such a thought before! Sorry I doubted you! Did a couple short tests before bed this evening. Confirmed that RC4 recovers when manually disabling/re-enabling WideFS via FSUIPC as suggested. Oddly enough, the hotkey restart still freezes RC4... so won't be using that "function" anymore. Strange. You'd think it would do they same thing. I'll take a look at making the hotkey version work. Probably the delay just isn't long enough to make the Client timeout and retry properly. It needs to go into "waiting for connection" mode. That might take many seconds actually, so I'll see if there's a more certain way of detecting it. I've not got time for this now till Thursday, but I'll be in touch after then. Pete
mach2000 Posted August 11, 2015 Author Report Posted August 11, 2015 Hey, that's a good idea! I had completely forgotten I'd had such a thought before! Sorry I doubted you! Not a problem... and understandable considering the amount of functionality packed into your programs. There have been many occasions that I've thought, "I wish FSUIPC could do this" only to discover in the documentation that "this" had already been implemented. Probably the delay just isn't long enough to make the Client timeout and retry properly. It needs to go into "waiting for connection" mode. That might take many seconds actually, so I'll see if there's a more certain way of detecting it. I think that's exactly the issue with the hotkey restart. I don't think the client ever went into "waiting for connection". I'm not at my home computer, but I believe Wideclient logged something akin to a "block error" and complained that it was expecting an orange (in hex) and got a banana instead... I'm paraphrasing, of course.
mach2000 Posted August 12, 2015 Author Report Posted August 12, 2015 It worked !!! For some reason, it took two disables/re-enables to get RC4 to recover; but after the second restart, it resumed with no problems. I'm not sure why it didn't work the first time... I verified that wideclient had dropped connection and it reconnected after the server restarted; but RC4 continued to claim that the IPC Request contains bad data. Thankfully, the second time was the charm (maybe there was still some garbage in the buffers that took some time to be processed out... but that's just an uneducated guess). Anyway, for my purposes, disabling/re-enabling the server solved the problem. If I may be so bold... when you get a chance to look at the hot-key restart, is there any way to implement a timer so that I can have wideserver reset automatically every 3 to 4 hours? This would save me from having to do it manually and may prevent the IPC bad data issue altogether. I know this may be asking a lot and may not be beneficial to other users; but thought I'd throw it out there. Thanks for helping me work through this.
Pete Dowson Posted August 12, 2015 Report Posted August 12, 2015 If I may be so bold... when you get a chance to look at the hot-key restart, is there any way to implement a timer so that I can have wideserver reset automatically every 3 to 4 hours? This would save me from having to do it manually and may prevent the IPC bad data issue altogether. I know this may be asking a lot and may not be beneficial to other users; but thought I'd throw it out there. Thanks for helping me work through this. Since the only purpose in resetting the Server is to make the Client reconnect, wouldn't it be better to make the client do it directly. It wouldn't need to wait for the timeout then. Did you ever try closing and restarting wideClient, or doesn't RC reconnect if you do that? It would be relatively easy to provide a parameter to specify an automatic reconnection timeout in wideClient. Please note, though, that I've spoken to a friend who also uses RC (one Ray Proudfoot, who you may have encountered on the RC Forum, and whose voice you will here in RC sometimes), and he says he has often left everything running overnight on a transatlantic hop and not had the problems you have been having. I'm pretty sure it's some function of the lower levels in the Windows + hardware networking system, and it most certainly shouldn't happen. Pete
mach2000 Posted August 12, 2015 Author Report Posted August 12, 2015 Since the only purpose in resetting the Server is to make the Client reconnect, wouldn't it be better to make the client do it directly. It wouldn't need to wait for the timeout then. To put a finer point on it, resetting the server terminates the bad data stream and provides a fresh new one. Assuming the corruption is occurring on the client side, I guess that would work; but if the problem is occurring on the server computer, it would just reconnect to the bad stream (I know you think it's a client side issue - but my gut is telling me it's server side) Did you ever try closing and restarting wideClient, or doesn't RC reconnect if you do that? Yes, that's the first thing I tried. It's not an option... RC chokes and will no longer respond. It would be relatively easy to provide a parameter to specify an automatic reconnection timeout in wideClient. Again, that would work if it's an issue on the client machine. I guess I favor resetting the server because I know for sure that it works and refreshing the connection at the source should clear up all problems downstream. Even a toggle would work for my purposes: Press hotkey, server shuts down... <wait 30 secs or so and ensure client is searching>... press hotkey, server starts up (basically what I'm doing now via the fsuipc interface, but less disruptive). I was just thinking that having it done automatically on a timer every few hours would refresh the stream and possibly prevent the corruption for the long legs where I may not always be in front of the computer. Please note, though, that I've spoken to a friend who also uses RC (one Ray Proudfoot, who you may have encountered on the RC Forum, and whose voice you will here in RC sometimes), and he says he has often left everything running overnight on a transatlantic hop and not had the problems you have been having. I'm pretty sure it's some function of the lower levels in the Windows + hardware networking system, and it most certainly shouldn't happen. Good to know... I have no doubt it is a very unique issue... could be hardware, could be the network driver... could be windows 7. I will say that I have no other networking problems whatsoever, so the bits must just be lining up wrong in this particular situation. I appreciate you helping me find a band-aid. Ray is a great guy... I've communicated with him on several occasions over at Avsim... he's always willing to help folks out. I wish JD hadn't given up on RC though... it's such a great program... but its age is starting to show. I was a controller for 15 years before taking my current job in automation, so ATC holds a special place in my heart.
Pete Dowson Posted August 12, 2015 Report Posted August 12, 2015 To put a finer point on it, resetting the server terminates the bad data stream and provides a fresh new one. Assuming the corruption is occurring on the client side, I guess that would work; but if the problem is occurring on the server computer, it would just reconnect to the bad stream (I know you think it's a client side issue - but my gut is telling me it's server side) No. The Server doesn't have a single "stream" each time something conects it's a new one. How else can it cope with multiple separate clients coming and going? You can test this by having another copy of Wideclient running on your one and only client PC, with perhaps one of the display Lua plug-ins showing frame rater, VAS or similar. You can run multiple WideClien's by setting the "ClassInstance" number to a non-zero value. I use three clients on one of my PCs, two running parallel ButtonScreens. These additional clients must use TCP protocol, not UDP because UDP isn't specific(i.e. it isn't addressable on the one PC). As I said it is much easier for me to put a reconnection timer into WideClient, with a parameter to set the elapsed time, and would also be smoother for you because there's be no need for the Client to delay before reconnecting. Okay, if that doesn't work as I believe it will, I'll look at the Server end. Pete
Pete Dowson Posted August 13, 2015 Report Posted August 13, 2015 Please try this updated WideClient.exe when you can: WideClient6999x.zip Before running it, set this parameter in the [Config] section: ReconnectMinutes=240 That would be for an automatic reconnection every 4 hours (4 x 60 minutes). Adjust to taste. (0 disables). The re-connection will just be a little hiccough, but it is going through exactly the same process as it would after a timeout triggered by a stoppage at the Server end. I think this should work fine for you, but if not do let me know and I'll implement some not-so-nice solution at the Server end. I'm away all next week, so if we miss this weekend I'm afraid there will be a week's delay. Pete
mach2000 Posted August 13, 2015 Author Report Posted August 13, 2015 Please try this updated WideClient.exe when you can: WideClient6999x.zip Before running it, set this parameter in the [Config] section: ReconnectMinutes=240 That would be for an automatic reconnection every 4 hours (4 x 60 minutes). Adjust to taste. (0 disables). The re-connection will just be a little hiccough, but it is going through exactly the same process as it would after a timeout triggered by a stoppage at the Server end. I think this should work fine for you, but if not do let me know and I'll implement some not-so-nice solution at the Server end. I'm away all next week, so if we miss this weekend I'm afraid there will be a week's delay. Pete Thanks Pete! I'll give it a try this evening and report back. I understand your point about new streams, pipelines, etc. being created with the re-connection, so hopefully this will work. We should have a verdict by tomorrow. Thanks again.
mach2000 Posted August 14, 2015 Author Report Posted August 14, 2015 Pete, Not that I'm telling you anything new, but you are truly a genius! The Client re-connection option appears to have completely resolved the issue. Did a 7.5 hour flight overnight and RC4 was working flawlessly in the morning. No errors... no bad IPC data... everything as it should be. Thank you so much! If you ever find yourself in the Atlanta area, let me know; I owe you a beer (or six). Hope you enjoy your upcoming holiday. Take Care, Marc Schrier
Pete Dowson Posted August 14, 2015 Report Posted August 14, 2015 The Client re-connection option appears to have completely resolved the issue. Did a 7.5 hour flight overnight and RC4 was working flawlessly in the morning. No errors... no bad IPC data... everything as it should be. Good. I'll make that version the official current release then. The logs at both ends will show the reconnection occurring, of course, but otherwise it should be pretty smooth. Pete
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now