Problems with WideFS 6596

[Wizball]

Hi..

I trying to test the latest beta WideFS version.. I have some troubles with it..

I have 5 client computers and 1 server with fs2004..

I have upgraded wideclient on all the clients and the wideserver on the server.

After the upgrade I can only connect one of the client computers to the server. The other clients wideclient.log says:

********* WideClient Log [version 6.596] Class=FS98MAIN *********

Date (dmy): 17/04/06, Time 00:14:39.425: Client name is xxxxxx

631 Attempting to connect now

1632 Trying to locate server: Need details from Server Broadcast

1632 Failed to connect: waiting to try again

2674 Attempting to connect now

35281 Trying to locate server: Need details from Server Broadcast

I have tried the both ProtocolPreferred= UDP and TCP on the server

I have tried to telnet from a client that not working to the server. Ill get a repons from the server on port 8002.

There is no firewall on my system.

But there is very strange that there is one computer that get connected to the server. (it is the same client every time) ..

Also using the same client config on all clients.

My clients are 4 WinXP and one Win2k..

The wideserver.log dosent say anything about any connection from the computers that I have problems with. It only logs the computer that works.

What is wrong ? :)

Best Regards

Tom Stian Bjerk

[Wizball]

standby on this.. Mabye I found some out here.

[Thomas Richter]

Hi Tom,

I switch also to the new WideFS version 6.596 and all is working OK.

I use UDP on FS2004-PC and on all 5 Clients.

FS2004 / MCP = XP Pro SP2

PFD / ND + PFD / ND-F/O = Win 2000 Pro SP4

EICAS = XP Pro SP2

CDU = Win 2000 Pro SP4

Hardware = XP Pro SP2

Quickmap/SquawkBox/FSInn/ServInfo = XP Pro SP2

********* WideServer.DLL Log [version 6.596] *********

Blocksize guide = 8192 (double allowed)

Date (dmy): 17/04/06, Time 00:21:20.413: Server name is P4-FS-3200

104250 Initialising TCP/IP server

104250 Initialising IPX/SPX server

104250 IPX/SPX socket() failed [Error=10047] Address family not supported by protocol family

104250 Failed to start IPX/SPX Server

104250 Initialising UDP/IP server

104250 Broadcasting service every 1000 mSecs

104250 Preferred protocol = UDP

104953 Connected to computer "AMD-FMC" running WideClient version 6.596 (IP=192.168.178.40) UDP

105984 Connected to computer "P4-PFD-3000" running WideClient version 6.596 (IP=192.168.178.22) UDP

106843 Connected to computer "AMD-HARDWARE" running WideClient version 6.596 (IP=192.168.178.50) UDP

144968 Connected to computer "P4-EICAS-2400" running WideClient version 6.596 (IP=192.168.178.30) UDP

144992 Connected to computer "AMD-Phidgets" running WideClient version 6.596 (IP=192.168.178.60) UDP

and the clients are also clean.

Did you set Server-Option to:

ProtocolPreferred=UDP

Did you set Client-Option to:

Protocol=UDP

Best Regards

Thomas Richter

[Pete Dowson]

I have 5 client computers and 1 server with fs2004..

Are you running winXP on all of them? If not then you'll need to provide the Server name to those which are not running XP, or all if the FS PC isn't running XP.

After the upgrade I can only connect one of the client computers to the server. The other clients wideclient.log says:

The log seems to indicate that those clients aren't receiving the Broadcast. Only XP can provide that facility.

This isn't a change from the previous version of WideFS. You didn't delete your previous INI files did you?

My clients are 4 WinXP and one Win2k..

Ah. Not sure about Win2K. What's the Server running?

The wideserver.log dosent say anything about any connection from the computers that I have problems with. It only logs the computer that works.

It won't see them unless they see the Broadcast, which they don't. The Clients have to send an "I'm here" message to the Server, but they can't when they don't know who the Server is.

I really don't think there's anything I have changed in this part of the mechanism which could result in these symptoms. I'd like to see the Server Log in any case, and maybe the INI files. Does the Win2K one normally work with the ServerName missing?

Regards,

Pete

[Pete Dowson]

Did you set Client-Option to:

Protocol=UDP

Hi Thomas,

You shouldn't need to set the protocol explicitly on the XP clients. That merely makes the "ProtocolPreferred" setting in the Server redundant, and the clients then have no choice.

I don't know about the Win2K ones -- does my Broadcast system work for those? i.e. do they connect okay without being told the ServerName or ServerIPaddr?

Regards,

Pete

[Wizball]

The server is running WinXP..

To get it to work I hade to set the

ProtocolPreferred=TCP on the server

and

Protocol=TCP on the clients .. without this the clients dident work..

When I defined UDP on the clients and the server I did get som errors in wideserver.log.

I will test a littlebit more tomorrow and will report it here..

So long

Best Regards

Tom Stian Bjerk

[Pete Dowson]

To get it to work I hade to set the

ProtocolPreferred=TCP on the server

and

Protocol=TCP on the clients .. without this the clients dident work..

Seems like the broadcasting isn't working anyway.

If you specify the Protocol in the clients the ProtocolPreferred parameter is totally redundant. It only affects what is transmitted in the broadcasts in any case, and you don't seem to be getting those.

However, without all that the Clients should default to TCP, and if that doesn't work they should then try SPX and UDP, in that order. They do here.

I still need more information please, including INI files and Server log.

When I defined UDP on the clients and the server I did get som errors in wideserver.log.

The Server initialises all of the protocols it can in any case, setting a protocol there is redundant -- you never did it before, remember?

I need to see the Log please!

Regards,

Pete

[Pete Dowson]

Okay, I found a problem in WideClient . I can only reproduce your Log if I stop my server broadcasting (by setting AdvertiseService=No in the server INI file).

For some reason it is now ignoring the ServerName and ServerIPaddr parameters UNLESS the Protocol is specified explicitly, and since is deletes "UseTCPIP=Yes" without replacing it, this presents a problem for those not using Broadcasts.

Anyway, the main indication in your case seems to be that the Broadcasting isn't working, so I still need to know what your Server is running and to see the INIs.

Meanwhile I'll fix the reading of the Server name or IP address details and re-issue WideClient only.

Thanks,

Pete

[Pete Dowson]

With WideClient 6.596 you either need to run it with Broadcasts operating correctly (i.e. on XP systems for Server and Client -- maybe Win2K though this is not yet clear), and the "AdvertiseService=1" parameter correctly defaulted in the Server INI files, and not have any Server details in the Client INI, OR you must specify not only the ServerName, IPAddress or Node but also the required Protocol.

If Server details are specified in the Client INI files, the broadcasts from the Server are ignored in any case. If Broadcasts aren't being used then there is no use for the "ProtocolPreferred" parameter in the Server INI, because by the time the Client can get this information it must already have sorted out a protocol.

I attach version 6.597 of WideClient (only -- the Server is not affected) which is similar, but operates correctly in that if you omit the Protocol parameter and specify the Server name, address or node details, the protocol is chosen automatically -- with SPX preferred if a Node is specified and TCP preferred otherwise. In either case, Broadcasts from the Server are ignored because you are specifying the Server explicitly, locally.

The ideal situation, reflected in the default INI settings, is for all PCs in the system to support the Mailshot broadcasts (i.e. be using WinXP), and for the only protocol specification to be the ProtocolPreferred one in the Server's INI. There would be no need for any Server details or Protocol in the Client INI.

This setup would allow you to test any of the three protocols across all clients by only changing the preference in the Server INI.

I hope this is clear. I am trying to make things very simple, but it is quite difficult when there are so many possible exceptions! ;-)

Regards,

Pete

WideClient6597.zip

[Wizball]

Great .. will try the new version tomorrow .. :) ..

I have to sleep now :)

So long..

Tom Stian

[Thomas Richter]

Did you set Client-Option to:

Protocol=UDP

Hi Thomas,

You shouldn't need to set the protocol explicitly on the XP clients. That merely makes the "ProtocolPreferred" setting in the Server redundant, and the clients then have no choice.

I don't know about the Win2K ones -- does my Broadcast system work for those? i.e. do they connect okay without being told the ServerName or ServerIPaddr?

Regards,

Pete

Hi Pete,

here are the logs from:

FS2004-PC (XP Pro)

and 3 clients (2* Win 2000 Pro and 1* XP Pro)

[Pete Dowson]

here are the logs from: FS2004-PC (XP Pro)

and 3 clients (2* Win 2000 Pro and 1* XP Pro)

Got them by email. Thanks. No INI files though.

The logs looks fine, excepting one little error on one Client:

105402 UDP connectionless mode set up okay!

105422 Error on send() of 215 bytes [Error=10057] Socket is not connected

That occurs so soon (20 mSecs) after the "connection" (odd term for a so-called connectionless link, but I don't know what else you'd call it! ) that I think it must just have run foul of some setting-up still happening in the Server. I'm not getting that on any of my 9 or 10 clients here, but I may see if I can deal with it before User release.

It looks good on Win2000 Pro so I'll change my documentation to say the broadcasting ("AdvertiseService") facilities work okay on that too. Thanks! I assume Win2000 non-Pro will be okay too.

Now, please try it all with the "Protocol=UDP" lines removed from all the WideClient.INI files (as you implied you'd set), so that the "ProtocolPreferred" setting is effective. That will allow you to compare UDP with TCP with SPX with only one parameter change. ;-)

Oh, please also update to WideClient 6.597 first, just to be sure we are all using the same things.

Thanks again!

Regards,

Pete

[Pete Dowson]

I've just realised the source of some of the confusion, and a weakness in my design. in trying to make it simple and automatic, and altering folks' INI files directly, I have actually mucked things up a little.

I am attaching yet another WideClient -- 6.598. In order to clarify the assorted configuration possibilities out I shall tabulate them, thus:

Case A: Server not specified in Client INI

(In other words, no ServerName, ServerIPAddr or ServerNode parameters).

In this case both the WideServer PC and the WideClient PC must support mailslots (i.e. run Win2K or XP), and the "AdvertiseService" parameter in the WideServer INI must not be set to "No" (it defaults to "1", for 1 second intervals).

Sub-case A1: Protocol is set in the Client INI:

This protocol is the one which will be used by the Client. If it isn't installed you'll get an error.

Sub-case A2: Protocol is not set in the Client INI:

The protocol tried first is the one specified by the Server in "ProtocolPreferred". If there is none, TCP is assumed. but in either case, the client will try others if the initial one is not installed (in order TCP-SPX-UDP, cyclic).

Case B: Server is specified in Client INI

(In other words, at least one of ServerName, ServerIPAddr and ServerNode parameters are provided).

In this case the Client can work with or without Server mailslots operating to this Client PC. This depends on whether the protocol is set:

Sub-case B1: Protocol is set in the Client INI:

Broadcasts from the Server are ignored altogether. This protocol is the one which will be used by the Client. If it isn't installed you'll get an error. If the Client cannot find the specified Server you'll get an error.

Sub-case A2: Protocol is not set in the Client INI:

Broadcasted mailslots from the Server are needed. Only broadcasts from the specified server will be accepted -- this prevents the client from connecting to a different Server when there are more than one.

The protocol tried first is the one specified by the Server in "ProtocolPreferred". If there is none, TCP is assumed. but in either case, the client will try others if the initial one is not installed (in order TCP-SPX-UDP, cyclic). This is true no matter which Server identification system is used (name, address or node).

Existing users upgrading for version 6.51 or earlier

First, a potential problem for early testers:

The previous two interim Wideclients (6.596 and 6.597) will have deleted the "UseTCPIP=Yes" parameter and not replaced it. If the Server is identified in the Client's INI file, then broadcast mailslots will now be needed even if they weren't before, and this will cause problems on non-XP/2K setups.

Solution: edit the relevant INI files and add "Protocol=TCP" (or whichever you want to try).

For users who've not yet tried 6.596 or 6.597, I've made the solution work in WideClient 6.598, as follows:

If the Client INI contains UseTCPIP=Yes and also identifies the Server in any of the three ways possible, then the UseTCPIP=Yes parameter is replaced by "Protocol=TCP" automatically.

Otherwise, if the Server isn't identified, it is assumed that the mailslots have been used successfully, so the Protocol parameter is omitted altogether.

Phew! Any questions?

Regards

Pete

WideClient6598 only.zip

[Wizball]

I have not tested the 6598 yet, but have tested the 6597.

I still have problems to get the Broadcast to work.. The client wont connect if I dont define the servername and Protocol in the wideclient.ini.

And another problem..

If I use UDP on the clients and I restarting the FS2004, the clients wont reconnect. I have to restart wideclient.exe on every client. But with TCP it works great..

Here is my sample of my wideserve.ini

[Config]

AdvertiseService=1

AutoRestart=0

AutoUpdateTime=13

MaximumBlock=8192

NoStoppedRestarts=Yes

Port=8002

RestartTime=10

SendTimeout=15

TCPcoalesce=No

ProtocolPreferred=UDP

[ClientNames]

1=WHITESTAR

2=ZAGREB

3=TSBFLIGHT2

4=TSBFLIGHT3

5=TSBFLIGHT4

And my wideclient.ini

[Config]

ButtonScanInterval=20

ClassInstance=0

NetworkTiming=5,1

PollInterval=2000

ResponseTime=18

ApplicationDelay=0

TCPcoalesce=No

WaitForNewData=500

MaxSendQ=100

OnMaxSendQ=Log

NewSendScanTime=50

Priority=3,1,2

Window=75,81,593,489

Port=8002

ServerName=Hanibal

Protocol=TCP

This is now my working config. If I remove the servername and protocol from the wideclient.ini it wont work.

Best Regards

Tom STian Bjerk

[Pete Dowson]

I still have problems to get the Broadcast to work.. The client wont connect if I dont define the servername and Protocol in the wideclient.ini.

It most certainly sounds like the Server doesn't support mailslots. you still haven't told me what operating system version you have there. Is it SP1 or 2 or the earlier (bug-filled) version?

If I use UDP on the clients and I restarting the FS2004, the clients wont reconnect. I have to restart wideclient.exe on every client. But with TCP it works great..

That's even odder. I'd need to see a client log of that -- it should be less of a problem on a "connectionless" protocol like UDP than either TCP or SPX, as neither end have a dedicated "socket" for that "connection" -- they simply send and hope the other receives.

It is even more important that we discover exactly what it is you are using for an operating system on the Server.

If I remove the servername and protocol from the wideclient.ini it wont work.

That definitely means mailslots aren't being supportedvery odd. I need to know versions of Windows on both Server and Clients so i can publish limitations.

Regards,

Pete

[Wizball]

My server is WinXP Pro with SP2 , my clients are 4 WinXP Pro with SP2 and 1 Win2K SP4.

Hmm.. Now I get confussed.. The reconnect with UDP Protocol works now. I have tested it many times that the result was that is was not working.

But I tried now and it worked. But the diffrent now was that I only tested 1 client with UDP, the others client is using TCP.

So I dont have any log for you at the moment :)

[Pete Dowson]

My server is WinXP Pro with SP2 , my clients are 4 WinXP Pro with SP2 and 1 Win2K SP4.

Well, it is then very very strange that mailshots don't appear to work. I don't understand that. Could they be blocked somehow in your settings?

:-(

Pete

[Thomas Richter]

My server is WinXP Pro with SP2 , my clients are 4 WinXP Pro with SP2 and 1 Win2K SP4.

Well, it is then very very strange that mailshots don't appear to work. I don't understand that. Could they be blocked somehow in your settings?

:-(

Pete

Hi Pete,

will try again, new logs from all 5 clients with WideClient 6598 and from WideServer.

[Pete Dowson]

will try again, new logs from all 5 clients with WideClient 6598 and from WideServer.

Hi Thomas,

I don't like the look of your logs with block sequence errors. Because UDP is not guaranteed, I suspect when there's a clash somewhere in the Network (hub, switch or router?) it simply loses the blocks, whereas TCP and SPX re-send.

For some less critical display, like a map or some instrument readout without consequence, it may not matter much if the odd blocks are lost, but otherwise you might need to consider going back to TCP, or finding out why your Network is rather unreliable (at least for two clients -- AMD-HARDWARE and, really bad, AMD-FMC).

Are you using a switch or hub? I think a hub is more likely to suffer from traffic clashes. I use switches all round and have no sequence errors with UDP on 10 clients.

Regards

Pete

[Thomas Richter]

will try again, new logs from all 5 clients with WideClient 6598 and from WideServer.

Hi Thomas,

I don't like the look of your logs with block sequence errors. Because UDP is not guaranteed, I suspect when there's a clash somewhere in the Network (hub, switch or router?) it simply loses the blocks, whereas TCP and SPX re-send.

For some less critical display, like a map or some instrument readout without consequence, it may not matter much if the odd blocks are lost, but otherwise you might need to consider going back to TCP, or finding out why your Network is rather unreliable (at least for two clients -- AMD-HARDWARE and, really bad, AMD-FMC).

Are you using a switch or hub? I think a hub is more likely to suffer from traffic clashes. I use switches all round and have no sequence errors with UDP on 10 clients.

Regards

Pete

Hi Pete,

I think the reason of "block sequence errors" is that I runpmGetWeather on the same PC where CDU is running with NetDir.

Now I didn`t run pmGetWeather for one hour and all is OK.

Then I run pmGetWeather on a other PC for 10 minutes or so and all is OK.

All is running in the new UDP-mode. Four PC`s Win XP pro and two PC`s Win 2000 pro.

[Wizball]

Hi again..

I have tested much here now.

And I found a solution on the broadcast, but not exaclty the problem.

I installed FS2004 on another computer (this computer is a Media Center Edition w/SP2). also installed fsuipc and widefs on it.

On that computer the wideserve broadcast works as a dream. So the problem that I have with the broadcast on my other computer is a local problem I think.

It is very strange. The easiest solution is to reinstall the computer to fixes it. But will try to find out what is wrong with it first so that I can locate the bug on it :)

I will post it here if I find the problem.

Best Regards

Tom Stian Bjerk

[Pete Dowson]

... So the problem that I have with the broadcast on my other computer is a local problem I think.

...I will post it here if I find the problem.

Yes, please.

Regards,

Pete

[Pete Dowson]

I think the reason of "block sequence errors" is that I runpmGetWeather on the same PC where CDU is running with NetDir.

Now I didn`t run pmGetWeather for one hour and all is OK.

Okay. That does seem to confirm that the system assumes UDP blocks are "dispensable", that if there's a clash the UDP block is lost and not re-sent. With TCP and SPX, if there's a timing clash anywhere I think the block is re-sent. The sender "cares" about the block getting there, but not with UDP.

Then I run pmGetWeather on a other PC for 10 minutes or so and all is OK. All is running in the new UDP-mode. Four PC`s Win XP pro and two PC`s Win 2000 pro.

That is a good solution then,

Do you notice if things are smoother, or about the same as with TCP or SPX? I think my PM gauges look smoother (so the block timing is better, less latency from the replies confirming receipt presumably), but it is very subjective. As with FS's own "smoothness", the frame rates are no measure for this -- WideServer regulates the frame rates to match FS in any case. The only time they will appear to exceed the FS rates is when the data from one frame needs to be split into more than one block to keep within protocol and buffer limits.

Regards,

Pete

[Thomas Richter]

I think the reason of "block sequence errors" is that I runpmGetWeather on the same PC where CDU is running with NetDir.

Now I didn`t run pmGetWeather for one hour and all is OK.

Okay. That does seem to confirm that the system assumes UDP blocks are "dispensable", that if there's a clash the UDP block is lost and not re-sent. With TCP and SPX, if there's a timing clash anywhere I think the block is re-sent. The sender "cares" about the block getting there, but not with UDP.

Then I run pmGetWeather on a other PC for 10 minutes or so and all is OK. All is running in the new UDP-mode. Four PC`s Win XP pro and two PC`s Win 2000 pro.

That is a good solution then,

Do you notice if things are smoother, or about the same as with TCP or SPX? I think my PM gauges look smoother (so the block timing is better, less latency from the replies confirming receipt presumably), but it is very subjective. As with FS's own "smoothness", the frame rates are no measure for this -- WideServer regulates the frame rates to match FS in any case. The only time they will appear to exceed the FS rates is when the data from one frame needs to be split into more than one block to keep within protocol and buffer limits.

Regards,

Pete

Hi Pete,

Yes.

I wrote down the PM-Frames, Datarates and FS-Frames (Read over PM "F" on all PC`s) before I made any changes (WideFS 6.51) and after installing the WideFS 6.596/8.

With 6.51:

Frames = 78-90

DataRate = 22-31

FS-Frames = 21-29

With WideFS 6.596/8:

Frames = 80-92

DataRate = 40-44

FS-Frames = 34-44

This both test I made under the same conditions, saved situation on same Airport with same plane and weather, all the same .

And I can reproduce it.

When I fly the PFD/ND and PFD/ND (FO) are smoother, also the other PC`s.

I made yesterday night a flight, more than 1 hour, and NO "block sequence errors" or anything else.

In Log`s only the beginning with programstarts and when I closed the Ends, nothing more.

Great, as ever.

Thanks Pete

[Pete Dowson]

With 6.51:

Frames = 78-90

DataRate = 22-31

FS-Frames = 21-29

With WideFS 6.596/8:

Frames = 80-92

DataRate = 40-44

FS-Frames = 34-44

...

And I can reproduce it.

That's quite an astounding difference, much more than I could have reasonably expected. I am very pleased it all works so well for you. I've not actually done any numerical comparisons like you, only watching everything subjectively.

Thanks!

Pete