Jump to content
The simFlight Network Forums

IPC Request contains bad data - only on long flights


Recommended Posts

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?

Link to comment
Share on other sites

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 7
Module base=628B0000
User Name="Marc Schrier"
User Addr=xxxxxxx@xxxxxxx
FSUIPC4 Key is provided
WideFS7 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
 

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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 free
Read buffer usage:  21973 alloc, 21973 free, max in session: 1
Write buffer usage: 1794136 alloc, 1794136 free, max in session: 1
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
********* 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) *********

 

Link to comment
Share on other sites

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
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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 :).

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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).

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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 account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.