Jump to content
The simFlight Network Forums

WideFS does not connect to FS9 any more


Recommended Posts

Hello,

 

I've been flying for years now with my main FS9 computer and a side laptop using WideFS. They have always been in a local network and configured with the basics. Both have Windows XP SP3

I recently moved but brought everything along and the same setup. And... I have had it working for about 2 months. The only difference was that the laptop was now connected via Wireless instead of fixed cable. Nevertheless I've tried with a small switch and the problem persists.

 

And what is the problem? Well I can't get WideFS to work. When I open WideClient, it opens the small window as usual but on the FS9 window it always says "waiting for clients". The laptop has internet, web, local shares, TCP/IP is working, I can ping servers and all.

The laptop is using account Administrator. If I start WideClient with right-click RunAs, Administrator but with the "Protect my computer and data from unauthorized program activity" it will get FS9 to detect one client, but then all applications that use WideFS say it has a fishy protocol and it won't work.

I've turned firewall off: still the same

I've turned McAfee antivirus off: still the same

 

The WideClient.ini config (which has never changed) is:

 

; PLEASE SEE WideFS documentation for parameter details
; =====================================================
 
[Config]
ServerIPAddr=192.168.1.10
Port=8002
Window=0,701,444,37
Visible=Yes
ButtonScanInterval=20
ClassInstance=0
NetworkTiming=5,1
MailslotTiming=2000,1000
PollInterval=2000
Port2=9002
ResponseTime=18
ApplicationDelay=0
TCPcoalesce=No
WaitForNewData=500
MaxSendQ=100
OnMaxSendQ=Log
NewSendScanTime=50
Priority=3,1,2
[Sounds]
Path=C:\Documents and Settings\Administrator\Desktop\WideFS\Sound\
Device1=Primary Sound Driver
Device2=SigmaTel Audio
Device3=C-Media USB Headphone Set
 

 

 

If I telnet into the FS9 machine on port 8002 it connects.

 

Now... can anyone solve the mystery?

Link to comment
Share on other sites

It is always useful to see the Log files -- that is what they are for. There's a WideServer log file on the Server and a WideClient log file next to the INI file you've shown.

 

Note that your INI file is missing an essential parameter. If you specify the Server IP address you MUST also set the protocol, i.e.

 

Protocol=TCP or

Protocol=UDP

 

Pete

Link to comment
Share on other sites

Hi Pete,

 

Thanks for the reply. I was coming back to say I had solved the issue since I found the old configuration file in another computer and it indeed had the Protocol=TCP line there. As soon as I added it everything was fine again.

 

But the log wasn't really clear for me. It did mention IPX/SPX, I just couldn't understand why. Apparently, if no line is present, it assumes IPX as default. Nevertheless I never changed the config file. I think it was because of an unstable Wireless in the laptop which probably made WideFS think: can't work with TCP so let's go to defaults. But instead of leaving the "Protocol=" line, it simply deleted it.

 

Thanks for the reply

Link to comment
Share on other sites

Pete, would it make sense now to default to TCP as the protocol?

 

Normally no parameters need to be added to the client INI file, because the broadcasts from the server end provide both the server details and the protocol to be used. The documentation is clear that if you add explicit Server details to the client parameters, you need the protocol to be explicit too. I see no harm in that, and it has been that way now since day one of WideFS, back in FS98-2000 days. 

 

Of course, back then the protocol of preference would have been IPX/SPX, being lean and mean and efficient. Only the lack of support for it from Microsoft (it being a Novell invention, not MS) makes the choice now either TCP or UDP, and if there were to be an assumed default, UDP might often fit the bill better, being, again, more efficient, especially combined with using a broadcast setup at the Server ("BroadcastMode=Yes", whereby the same data is sent once, to all clients, instead of each client getting its own tailored data).

 

My setup, with 7 clients, uses UDP and broadcasting on all clients except one, the one used for Radar Contact, where it is very important for all the commands being set TO the server to be in the correct order, something that UDP cannot guarantee.

 

Pete

Link to comment
Share on other sites

Thanks for the reply. I was coming back to say I had solved the issue since I found the old configuration file in another computer and it indeed had the Protocol=TCP line there. As soon as I added it everything was fine again.

 

Yes, the instructions in the section in the WideFS User Guide about configuring the network (the part with the red warning to read at least part of it) is explicit that you need BOTH lines, not just the one.

 

But the log wasn't really clear for me. It did mention IPX/SPX, I just couldn't understand why. Apparently, if no line is present, it assumes IPX as default.
 
No, that's not true. If you don't give the Protocol it needs the Server to tell it through its broadcasts. It's one or the other -- specify details in the client parameters, or leave to to the Server broadcasts.
 
Nevertheless I never changed the config file. I think it was because of an unstable Wireless in the laptop which probably made WideFS think: can't work with TCP so let's go to defaults. But instead of leaving the "Protocol=" line, it simply deleted it.
 
No, parameters are never deleted. There is no Protocol parameter there by default so that you can choose it for all clients at the server end. You only supply a Protocol parameter to override the one set at the Server end.
 
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.