Jump to content
The simFlight Network Forums

autostart of progrmas


Recommended Posts

Hi Peter,

Installed the latest 3.601 on my PCs and I have put in the clients the serverName=ipaddr in each ini file and put the protocol= UDP

Everything seemed to work as before at first glance.

However after starting up all my PCs today I found the following.

Normally I start all my PCs at ones and the PC running FS is the

fastest but the slowest in booting. So all PCs are running wideclient

before FS starts. WHen it finally comes online the client see this

and start there applications. This doesnt happen anymore

they stay without connection. If I shut the wideclient and start it

up again (server is running already) everything is OK

Greetz

Peter

Belgium

Link to comment
Share on other sites

Installed the latest 3.601 on my PCs and I have put in the clients the serverName=ipaddr in each ini file and put the protocol= UDP

3.601 is an FSUIPC version number but the parameters you are talking about relate to WideFS.

Normally I start all my PCs at ones and the PC running FS is the

fastest but the slowest in booting. So all PCs are running wideclient

before FS starts. WHen it finally comes online the client see this

and start there applications. This doesnt happen anymore

they stay without connection. If I shut the wideclient and start it

up again (server is running already) everything is OK

You may have something bad going on with UDP causing a jam -- maybe you use a hub, not a switch? I do exactly as you and everything connects fine. Try TCP or SPX.

Please note that there is no way I can offer detailed assistance without knowing more -- in this case WideFS version number, WideClient and WideServer INI and LOG files.

Regards,

Pete

Link to comment
Share on other sites

Well Peter,

you're rightit was late last night.

I have installed also the latest widefs version found on the forum

and the change to UDP was in the light of this new version.

I use a switch for my network connection.

Anyway when I start first the Fs running PC, start FS and sit somewhere on the tarmac, then I start the client PC -> I have no problems with this new version and with an ethereal application I see the UDP messages going back and forth.

However, when I start first a wideclient while the FS is not running yet, then I start the FS then the client stays in waiting for connection and it doesn't connect.

When in this state I stop the wideclient and restart is (now server is running)

I got no problem and the connection start immediately.

Will make some logs when I got time ....

I was thinking maybe there is a change since UDP is connection less

while TCP is connection oriented and will retry until the server comes up

Greetz Peter

Belgium

Link to comment
Share on other sites

Just made some checks and here is a logfile.

For some reason when FS starts up it send a shutdown code to the

client PC

When FS is running already the connection is made instantly

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

Date (dmy): 15/05/06, Time 21:25:28.170: Client name is MCDUDISPLAY

625 Attempting to connect now

656 Trying UDP/IP host "10.0.0.5" port 8002 ...

656Okay, IP Address = 10.0.0.5

656 UDP connectionless mode set up okay!

875 Error on recv() [Error=10054] Connection reset by peer

875 Attempting to connect now

875 UDP connectionless mode set up okay!

875 Received shutdown offset code = ADBC

875 FS closing down (param=ADBC), disconnecting

875 ********* Interim performance summary *********

875 Total time connected so far = 0 seconds

875 Reception maximum so far: 0 frames/sec, 0 bytes/sec

875 Transmission maximum so far: 0 frames/sec, 0 bytes/sec

875 Max receive buffer = 0, Max send depth = 1, Send frames lost = 0

875 ***********************************************

Link to comment
Share on other sites

Just made some checks and here is a logfile.

For some reason when FS starts up it send a shutdown code to the

client PC

When FS is running already the connection is made instantly

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

Date (dmy): 15/05/06, Time 21:25:28.170: Client name is MCDUDISPLAY

625 Attempting to connect now

656 Trying UDP/IP host "10.0.0.5" port 8002 ...

656Okay, IP Address = 10.0.0.5

656 UDP connectionless mode set up okay!

875 Error on recv() [Error=10054] Connection reset by peer

875 Attempting to connect now

875 UDP connectionless mode set up okay!

875 Received shutdown offset code = ADBC

No, this isn't a shutdown code from the Server, it is generated inside WideClient because of this:

Error on recv() [Error=10054] Connection reset by peer

With UDP (only), being connectionless, it is the only way I can actually be sure to see when FS is closing -- the error 10054 should only occur because a server Port which we received from now says it is disconnect.

I don't know why you are getting that immediately like that (it doesn't happen here), and what is even odder, it is being logged before the Client even lgs the connection succeeded.

For now use TCP or SPX. I will have to think about this -- I thought I could rely on Windows errors such as this, but it seems not. Maybe I have to ignore the first few or something. :-(

Please tell me, what Windows versions are you using, Client and Server?

Regards,

Pete

Link to comment
Share on other sites

Pete,

I am using winXP (I think I updated to SP2 on all of them)

I forgot also to mention that I installed yesterday the latest wideclient

on an older computer (WinMe) that I use to develop my hardware scripts

and there I did not have this problem!!!

Greetz Peter

Link to comment
Share on other sites

Pete,

I am using winXP (I think I updated to SP2 on all of them)

For an all WinXP setup you shouldn't need to specify Server name or IPaddress, or even protocol -- you can set a PreferredProtocol in the Server. The Clients will find the Server automatically provided all PCs are Win2000 or WinXP, and all in the same WorkGroup. Then this problem wouldn't arise.

I forgot also to mention that I installed yesterday the latest wideclient

on an older computer (WinMe) that I use to develop my hardware scripts

and there I did not have this problem!!!

I don't get the problem here in any case, I've been trying to reproduce it -- it is certainly some sort of timing difference. If you have a WinME client, that will certainly need the server and protocol set. The auto stuff won't work on WinMe or Win98.

If I determine a way of preventing the problem I may need to ask you to test it for me, please.

Regards,

Pete

Link to comment
Share on other sites

Peter,

to test a possible solution to this I'dd be happy to assist.

The current workaround is to start first FS and position the plane on the gate

then I start the client PCs and this gives no problems

I'll continue for now this way in order not to change all the ini files

so if you got something regarding this to test it doesn't take me much to do so.

If there is anything else you needjust send me mail at peter(dot)depoortere(add)skynet.be and peter(dot)depoortere(add)alcatel.be

the last address is being checked very often since it in my work

but i got from work no access to my PCs at home

Greetz Peter

Belgium

Link to comment
Share on other sites

Pete,

I tested it with winXp Pro and there it was OK with the latest version

and it was faulty with the previous version (as above)

Tonight I'll put it also on my other PCs with XP home.

But it looks better now since on the XP Pro I saw also the disconnection

in the logfile as on the XP home ones.

Greetz Peter

Belgium

PS : send also as Private Mail

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.