FSHost can not connect more than 5 players

sonjamichelle · January 13, 2005, 04:38:42 AM

Here's an email, that I am forwarding on to the forum about an issue we're having with our FSHost server.

<----quote------->

System: OS WinXP Pro sp2

   P3 1.3ghz

   512megs memory (170 megs free)

   Servers running normally:

- Apache 2

- KDX (2 servers)

- FShost

- VNC server

- Serv-U FTP server

- MDaemon mail server

- Teamspeak

Computer with all this running, people using the KDX servers (connected to them), teamspeak server, and fshost server (both with 4-5 people on them) uses about 40-50% CPU and from 12-18 KPS output. I am fully capable of pushing 75k/sec out and receiving 6mb/s.

Most of the time, if there are 5 of us flying on the server (fshost) then a sixth connects, one of the others gets booted. They can not reconnect at all. OR, the extra person can not ever connect. FSNavigator will only see the server 1/3 of the time. Sometimes, no problems at all.. Others, no matter what you do, or how many people, it will simply NOT see the server.

I run Panda firewall. FShost is allowed and I have of course, turned it off completely with no better results. Linksys router with ports 23400-23500 open to fshost. I have also tried fshost with other servers shut down, and the same thing happens. I have it set to allow unlimited pilots and observers. I could see a problem if I had limited bw, but since we never even hit 20k/sec and I can push 75k/sec with no problems, I just don't get it.

<----end of quote----->

That's about it in a nutshell. We're rather boggled by what's happening. Thoughts? Suggestions?

Russell Gilbert · January 13, 2005, 06:14:40 AM

Hi,

This sure sounds like a networking issue related to ports to me.

You mentioned ports 23400-23500, but I've never heard of those ports before. Are you forwarding all of the ports mentioned in the Help page?

Russell

sonjamichelle · January 13, 2005, 06:45:35 AM

23400-23500 tells the router to forward all ports between that range. This will get 23456 and all the other ports within a 100 around it.

I'll mention to Greg the dplay ports as well, could be the issue there.

Russell Gilbert · January 13, 2005, 07:02:45 AM

It's good to forward 23456, but the other ports around it aren't necessary unless you're setting FSHost to use one of them for the FS2004 session.

The important ones are the others mentioned in the help file, which are used by DirectPlay, as you said. When a player connects to your server on 23456, everything's fine, and both sides end up using that one port. But some players aren't able to use that port, either because they've changed the settings in their own FS or because of their network situation, which essentially changes the port to another one by the time it gets to your server (basically a proxy-type situation). And FSNav uses a completely different port also. In both of these cases where it's not using 23456, it ends up falling back to the DirectPlay default ports, which are UDP 6073 and a semi-random port in the range of UDP 2300 to 2400. If you don't have those forwarded, then it could definitely explain why only some people are able to connect, and why you're having so much trouble with FSNav.

Anyway, give it a shot and hopefully it'll take care of the problem.

Russell

SpectroPro · January 15, 2005, 05:08:57 AM

This problem is occuring to people all over. They may not have noticed it yet, but we have found this problem on servers all over the place. ALL the ports that need to be forwarded are. I have even shut down all protection for the computer and the same happens.

You helped me once before. Spent several days with me trying to figure out a connection problem when I connected to my server locally, everyone else got booted. That is fixed, but this one is really annoying as we have many people that wihs to join our flights.

sonjamichelle · January 15, 2005, 05:43:41 AM

Ok, here's some more information:

Connecting to 69.133.200.139 default 23456 (Greg's server) I can connect FS2004, but never FSNav any port I can also connect ATC Radar Screen v5. port 23456 Now when we get more than 5 people Then I can only connect one or the other but not both. Then oif course there is the fact that no one else can conect as well.

Connecting to 67.38.117.13 default 23456 (virtualpilot.net) I can connect FS2004 port 23456, FSNav port 23432, and ATC Radar Screen port 23456

Connecting to 213.114.28.163 port 23452 (AirSource VPU session) I can connect FS2004, but not FSNav on any port. I can connect ATCRSv5 on port 23452 as well. However I had a pilot who could not connect while there were 2 of us connected along with ATCRC and he was only able to connect one ATCRC was disconnected.

Connecting to 213.114.28.163 port 23456 (Public World 01 session) I can connect FS2004, but not FSNav any port. ATCRC can connect port 23456

Picking a host at random that had 12 pilots on 207.44.246.56 (airflyers) port 23456 I could connect FS2004 port 23456, FSNav port 23432 and was able to connect ATCRC port 23456.

And of course I can connect all through on a locally run FSHost, have not found anyone to test with me. (might be a good idea to get a bunch of us together and try different configs)

As I was writing this I noticed antother one of our pilots connect to ambaron (airsource session) with BOTH FS2004 and FSNav. Again, I cant connect FSNAv at all and I get reports from at least two other pilots of the same and at least 2 other folks who had no problems with FSNAv as well.

FSHost 3.0 and FSNav 4.6 have been out for quite some time with no updates. Not sure about ATCRC though I've had that since July or August, no updates there either. The only changes since then have been the release of FS2004 patch 1 and directx 9c.

I am totally and completely stumped!

sonjamichelle · January 16, 2005, 06:58:25 AM

We did a little test session last night. Greg completely opened the box, no firewall, no noththing. Guess what it all worked!!! But wait, we have everything mapped and opened that we should have. turns out that FS is doing something else in the background. We cam up with a few more ports that were being used:

ATCRC was on 65190

FSHOST was on 48457, 41560,47624
and DPNS (FS9 directx server) was on 26389

Doing a search on the net, port 47624 is a directx 7 mapping, seems like FS9 is using it too. We have a few text dumps of the connected processes from the server and my client and a raw udp stream from my router if ya want them.

Russell Gilbert · January 16, 2005, 07:06:21 AM

Hi,

Could you give us the definitive list of which ports you're forwarding, when everything is enabled and it's not working?

Thanks,
Russell

SpectroPro · January 16, 2005, 11:37:52 AM

QuoteIt's good to forward 23456, but the other ports around it aren't necessary unless you're setting FSHost to use one of them for the FS2004 session.

The important ones are the others mentioned in the help file, which are used by DirectPlay, as you said. When a player connects to your server on 23456, everything's fine, and both sides end up using that one port. But some players aren't able to use that port, either because they've changed the settings in their own FS or because of their network situation, which essentially changes the port to another one by the time it gets to your server (basically a proxy-type situation). And FSNav uses a completely different port also. In both of these cases where it's not using 23456, it ends up falling back to the DirectPlay default ports, which are UDP 6073 and a semi-random port in the range of UDP 2300 to 2400. If you don't have those forwarded, then it could definitely explain why only some people are able to connect, and why you're having so much trouble with FSNav.

Anyway, give it a shot and hopefully it'll take care of the problem.

Russell

Russell,
I had forwarded exactly the list you told me to long time ago, and that you reference here in the above quote. With those ports all open, we have the problem. This is on, and I forgot to mention in my email to sonja as she knew it already, fs2004 with the 9.1 patch and completely up to date Windows XP pro software and accessory software.

Thus, I am agreeing with Sonja, that if the ports you say MUST be open ARE open, and we and others still have the problem currently with all the current FS and MS updates installed, then MS has changed something in one of the updates. They did mention that there is significant FSMP updates in the 9.1 release. Maybe some were port issues. I would say that is the case. I know Sonja was sending you my dump from my computer with all the port info available to you. I hope that it helps in an upcoming update. Currently, for me to get FSH to work as it should (so far) I had to open that computer completely in the DMZ on the router. Luckily I run 2 firewalls on the server computer so I can at least still keep it safe.

Russell Gilbert · January 16, 2005, 12:02:51 PM

Hi SpectroPro,

Ok, just to be sure we're on the same page, this is the full list you should forward to support both FS2002 and FS2004:

TCP 47624
UDP 23456
UDP 6073
UDP 2300 to 2400

As for the 9.1 patch, there were no changes that affected any of the multiplayer part of FS9. I was on the beta team for it and read all their release notes, and I've done several tests myself, hoping I might find some changes ;-) I'm also quite certain there have been no changes to the DirectPlay ports in SP2, or any of the other updates to DirectX 9.

I haven't received any log files from Sonja, but I'm happy to look over what you have if you'd like to send them. You can use the email address in the Help / About box of FSHost.

Thanks,
Russell

SpectroPro · January 16, 2005, 12:26:23 PM

Yes, those are the ports that I had open on the router. And quite a few more just to be sure.

However, I did try with ONLY those open just to be sure more wasn't causing the problem.

A side note, if it matters, I have 2002 banned from the FSHost server in the options. I do NOT allow 2002 clients to connect.

This is directly from the update Read-Me file: "Fixed multiplayer support –
In certain scenarios, a failed DirectX installation caused Flight Simulator 2004: A Century of Flight to stop functioning when multiplayer sessions were initialized. This problem is fixed in the update."

This may not have affected anything port wise, but they changed something in the MP area, and as I am also a beta tester for many game companies, and you are a programmer, we both know that even adding or removing a space from a line of code can change things drastically in something else that has nothing to do with what you are doing.

Anyways, I am in the wishlist area now and looking forward to the next version with some of the goodies posted there in it.

Russell Gilbert · January 16, 2005, 12:35:34 PM

QuoteThis is directly from the update Read-Me file: "Fixed multiplayer support –
In certain scenarios, a failed DirectX installation caused Flight Simulator 2004: A Century of Flight to stop functioning when multiplayer sessions were initialized. This problem is fixed in the update."

Not that it's any big deal, but I interpreted that statement to mean that if someone had a messed up DirectX installation (i.e. there were errors listed on the Notes page of dxdiag), and they started FS9 and went to the multiplayer window to connect to a session, their FS9 might lock up. I believe they just handle the error better now, and probably report some kind of error saying DirectX needs to be reinstalled, rather than locking up. I don't believe it has any relation to other players in a session, or to FS2002. That being said, you're quite welcome to disable FS2002 if you like, some people have said they think their sessions are more stabile when there's only one session running -- if that's true, it could be attributed to DirectPlay being confused by two different versions trying to access the same ports at the same time. I don't really know though, lots of people seem to be ok with both versions running, and it could be that DP can handle that ok.

Russell

sonjamichelle · January 17, 2005, 01:37:23 AM

Russell,

Sent you an email with the location od the data files. Hopefully it got through. The first failed with a message that the server can't accept bad attatchments. Being that it was a zip files with three text files it err'ed on the side of caution and said no way!

sonjamichelle · January 18, 2005, 05:11:50 AM

We did the stress test last night. Was quite successfull! HEre the list of ports in use last night:

UDP 23456
UDP 23452
UDP 23432
UDP 6073
UDP 2300 to 2400
TCP 47624 (saw it on the stream but no one entered it into a client so it appears to be automatically used by one of the programs)

Of course these ports need to be forwarded on the router and open in the firewall. Might be a good idea to open a port range between 23450 to 23460 to catch all possibilities.

Now with 6 people connected 5 with cable/dsl one with dialup and each of us running FS AND FSNav and two of us running ATCRS (for a total of 14 peak connections) my inbound/outbound bandwitdh was running between 15k to 20k (got a meter on the router

) pretty steady through the night. Our dialup guy was able to fly with us with some degraded performance. He reported some hangs and jumpiness of course. During the session his TeamSpeak usage was too broken to for us to understand, yet he could hear us relatively decently, this could be also attributed to the chosen codec and was easily coountered by using the text chat.. I also think most of us are running with our FPS slider set to unlimited. Computer Pilot says this is the best setting as it lets FS choose what's best and actually improves your fps or something to that effect. (Greg: Issue and Page #?) Though there have been reports that limiting it during multiplayer sessions will give better performace on the net side of the house. That will be our next test.

So far that's what we have to date. We're doing another multiplayer session Saturday evening 8pm EST, I believe, as well as a VA mp event that afternoon (turnout for that so far has been 15-20 pilots each session), so we'll be able to get more data and reports.

Russell Gilbert · January 18, 2005, 07:03:46 AM

Interesting results.

With the exception of port 23452, all of those are expected. 23432 is the port FSNav defaults to. But even if you didn't have any of the 234xx ports open at all, most people would still be able to connect witih no problem, because they'll fall back to the "alternate" DirectPlay ports of 6073 and 2300-2400. It gets complicated, but basically if both sides can use a 234xx port, then that's the only port that gets used. But if for some reason it can't, then the initial connection is made on 6073, and then when the user presses the Join button, it switches to a random 2300-2400 port for the rest of the session. This is why FSNav's 23432 isn't actually always necessary, because it'll fall back as well if it's not forwarded. But there are cases where a person's network doesn't like switching from 6073 to one of the 23xx ports in mid-conversation, and that's why MS created the ability to use a single 234xx port for the entire session. (actually there's nothing magic about 234xx, it could be 1000 or 5000 or 44000, as long as both sides are set the same way)

TCP 47624 is what FS2002 uses when it's looking for the session (similar to how FS2004 uses 6073), so you probably had an FS2002 user in there somewhere.

As for the FPS slider... I'm surprised to hear that Computer Pilot is suggesting it be set to unlimited. My understanding of how it worked on the graphics side was that if you limited it to a lower number, it would allow the game engine to use the extra CPU cycles for other calculations besides just graphics. Most people can't tell a big difference in graphics performance above about 20 or 30 fps anyway, so why have the PC spend all that time producing up to 100 fps (I've seen this on a 3 GHz machine) when most of the fps are wasted?

But there's no question as to how it affects a multiplayer session. FS2000 and FS2002 sent multiplayer location packets to all other players in the session at a fixed rate of 4 times per second. For some unknown reason (I honestly believe it was an oversight), FS2004 sends location packets at the same rate as whatever framerate you're getting visually in the game. So if you're getting 100 fps, you're also sending location packets at a rate of 100 times per second. There are very few things in life that need to be done 100 times per second, and I can tell you that sending 80 or so bytes of data half way around the world to 10 or 20 or 30 other people is not one of them! I've done extensive tests with this, and I can tell you that once you get above 4 packets per second, there's very little difference in how smoothly the other players appear to move. This is why FSHost defaults to relaying packets between the FS2002 and FS2004 sessions at a rate of every 250 ms.

I usually suggest that people limit their fps to the lowest number they can live with graphically, which is often around 20 fps or so. When you're hosting a session with dialup players as well, this is critical, because all those extra location packets will just swamp the dialup players and they'll never be able to keep up with the bandwidth. On a good dialup connection, you can probably get about 5KB/sec, and less if it's a bad one. In an FS2002-only session, this would be about 3 to 5 players, but with the problem in FS2004, it can be far less than that depending on what fps people are using. This is what causes planes to jump backward and forward in the sky (you've probably seen it while they're landing), and it of course affects voice comms as well. Another situation where it's critical is when all pilots are flying in close proximity to each other, such as during a race. In this case, it's important to be able to see each other accurately, and the session admins often require that all players lock their fps to no higher than 20 or 25.

Anyway, as I said, interesting results.

Russell

sonjamichelle · January 18, 2005, 08:44:02 AM

I agree with the fps slider issue, it doesn't make sense that unlimited makes things better. I've been running unlimited for the past week or so and honestly, I don't see much of a difference. I do know that it makes a major difference on the network side. Would be nice to see a definitive answer from some authority on the slider issue. Immean, like you said, most folks cant tell the diffrence between 20 and 30. I believe the human eye really can't dicern much above 30 if at all.

SpectroPro · January 18, 2005, 12:43:29 PM

QuoteTCP 47624 is what FS2002 uses when it's looking for the session (similar to how FS2004 uses 6073), so you probably had an FS2002 user in there somewhere.

This would be acceptable except that I ban all 2002 clients. So this is actually NOT accurate and didn't happen. Not only that, but everyone that was there was on 2004.

QuoteAs for the FPS slider... I'm surprised to hear that Computer Pilot is suggesting it be set to unlimited. My understanding of how it worked on the graphics side was that if you limited it to a lower number, it would allow the game engine to use the extra CPU cycles for other calculations besides just graphics. Most people can't tell a big difference in graphics performance above about 20 or 30 fps anyway, so why have the PC spend all that time producing up to 100 fps (I've seen this on a 3 GHz machine) when most of the fps are wasted?

Both are actually accurate. I spent over a year pushing the LIMIT your fps slider to 1 or 2 below your normal average fps that you get. This allows for the cycles to go to other things. And the number is 22 fps. The human eye can NOT discern the difference of anything above 22 fpt. This is simply a fact and we don't need people saying they can tell. You can't. Sorry. I really love people that swear they can. Think what you want, science and eye doctors say you are wrong.

As for the other side, from what CP stated in their mag (looking through them to post the exact page and issue, will do ASAP) you should set the slider up to the max setting. NOTE, this simply removed the limit from your graphics card. Graphics cards run their own computations and thus do NOT affect the raw processing power of your cpu. That's why you have a cpu and a gpu.

Here is some info from an article on setting your sim up:

QuoteThe slider sets two values in your 2002.cfg file:

UPPER_FRAMERATE_LIMIT=xx (where xx is the value you set your slider to.)

This is located in the (Display) section of your 2002.cfg file and does exactly what it says. It locks your max frame rate to that value and then assigns additional resources to other tasks (such as smoothing guage motion, pre-loading scenery, etc.)

LOD_TARGET_FPS=xx (where xx is roughly 70% (rounded)of the value of the slider).

This is located in the (GRAPHICS) portion of the 2002.cfg file. This gives a "minimum" setting for Frame Rate.

If you maintain within this 30 percent bracket, the sim will pump out all the detail you have defined in the rest of your sliders. If you drift below the minimum, then it will start dropping detail in an attempt to get above the minimum. The first to go is texture detail, which explains the "muddy" or fuzzy textures people complain about. Some settings do not
seem to be affected. Autogen, for example does not seem to ever get turned off, where some people have reported loss of AI traffic, and loss of building detail (High Res Airports such as KORD).

Microsoft put this slider in the sim, to maintain the smoothness that we all love. Stuttering not only is aresult of RAW frame rate, but also the CHANGE of frame rate from one slice of time to another. This is most evident in turns. When you pass from a low density screen to a high density screen (such as going past New York City skyline), your FPS drops suddenly. If you were pushing 60 FPS and you drop to 20, the drop in frame rate is more noticeable than if you had been at 20 all the time.

To maintain proper operation of the slider, First determine your "comfort zone". Set the slider accordingly. Then tailor your other settings so that your sim can maintain that at all times in all (or most) conditions.

Some of you may want to override the slider instead. To override the slider, you need to do TWO things.
Setting the slider to unlimited merely removes the "roof" from the slider, It does not do ANYTHING to
the LOD_TARGET_FPS value. Thus if you previously had your slider set to 30FPS, then your minimum is still
LOD_TARGET_FPS is still set to 21.

To maximize your range, first set the slider to 10FPS (lowest setting), this will set LOD_TARGET_FPS to 7.
Exit and restart simulator to make sure the LOD_TARGET_FPS value is written and saved to the FS2002.cfg file. When restarting, then set the slider to unlimited. This will remove the limiter from your video card, while maintaining the lowest setting for LOD_TARGET_FPS so that detail is maintained.

(Another solution would be to set to unlimited, and then manually editing the FS2002.cfg)

Hope this clears up the mystique of the slider.

NOTE: it's the same for 2004.

So, that said, I will get that info up soon as I find the page and issue again. I have a ton to read through.

Now, for the part that will probably make some people made...but I just call them like I see them.

Seems that you Russell, and please don't take this the wrong way, but you will cause everyone does..hehe, don't want to admit that something in your program is NOT working properly. But apparently, there are things happening, and it is a new fupah, so NOT your fault, within FS and your program that don't like each other. Since MANY people seem to be having this problem currently, it apparently IS a problem. I do NOT run 2002 games, have it turned off, and have stated such several times on here. So, (and for the record, turning it off was YOUR recommendation long time ago) I get upset when you keep referencing it and making comments that it must be being used. I said it isn't, and that's what I meant.

Also, there is NO reason what so ever, unless the program (fshost) has some issue going on, that we should be forced to connect our clients to it in certain orders. MUST be aux programs (radar, etc..) THEN flight sim, THEN FSnav. Ports must all be different for each client. Very odd and should again NOT be necessary. I run other servers and have 100's of clients that connect to them all using the exact same port, and I use the exact same port with NO problems at all. Yet FSHOst HAS a problem. As I have been running servers for many many years, I can tell you, it IS a problem.

Again, may not be your fault, but again, it may be. I don't know, but please don't get so deffensive when we mention that there IS a problem.

Ok, that said...we will continue to feed you all the data we find on various servers so that you can figure out why this problem exists and how to fix it.

Now you can yell at me and kick me.....I can take it.

sonjamichelle · January 18, 2005, 01:15:23 PM

I'd tend to blame directx before FSHost or FSNAv since there have been no changes to their code in some time. HOWEVER FS has had at least one update. Direct X has had at least 1 or 2 major updates and now 3 minor updates to the last version itself. And let's not forget that SP2 has been released and the fact that there are numerous updates and fixes for windows on a pretty steady basis. And as has been proven time and time again, MS is not always forthcoming with what they have done, or could have done, or what could be broken. There is something going on, and with enough eyes on it, it will be located and a solution will be found, until the next problem arises.

SpectroPro · January 18, 2005, 01:29:21 PM

I agree Sonja, but again, you can't ask them to quit updating. The problem is that (again, I hope this isn't taken the wrong way) programmers don't keep up. I know it is free. I know it is a ton of work. But FSUIPC is a perfect example. He upgrades it to work with all the new things that MS does.

This doesn't mean you get to blame the upgrades. You have to look then at the programs like FSHost and others that do NOT upgrade. It's a fine line that pollitically correct people walk, especially when on the site of the program in question. (hehe) I don't walk that line....I smash it. Simple fact is that if MS changes their something, then the programs using it must also upgrade. MOST of these problems occured, or seem to have occured, with the release of SP2 and fs9.1 as well as upgraded DX,etc....

Russell Gilbert · January 18, 2005, 01:56:15 PM

QuoteThis would be acceptable except that I ban all 2002 clients. So this is actually NOT accurate and didn't happen. Not only that, but everyone that was there was on 2004.

Well, everyone that connected to the session was on 2004, anyway. But are you absolutely sure nobody tried to connect with 2002? As I said, TCP 47624 is used by FS2002 to find the session (when you click Search). Once it joins the session, it switches to a port in the 2300-2400 range. But anyway, I was just guessing that it might have happened, since that port is used by programs using the DirectPlay 7 method, and FS2002 was the most likely program that might've been using it. I obviously wasn't there when you were doing your testing, so I don't know what settings you used, or who tried to connect.

QuoteBoth are actually accurate. I spent over a year pushing the LIMIT your fps slider to 1 or 2 below your normal average fps that you get. This allows for the cycles to go to other things. And the number is 22 fps. The human eye can NOT discern the difference of anything above 22 fpt. This is simply a fact and we don't need people saying they can tell. You can't. Sorry. I really love people that swear they can. Think what you want, science and eye doctors say you are wrong.

You may be interested in this page that discusses that topic a bit more:

http://www.100fps.com/how_many_frames_can_humans_see.htm

QuoteAs for the other side, from what CP stated in their mag (looking through them to post the exact page and issue, will do ASAP) you should set the slider up to the max setting. NOTE, this simply removed the limit from your graphics card. Graphics cards run their own computations and thus do NOT affect the raw processing power of your cpu. That's why you have a cpu and a gpu.

I'm not sure that's completely accurate -- certainly the cpu is involved somewhat, since the game has to send all that data to the graphics card, and do other things related to processing each frame of video. The gpu certainly helps with the raw computations, but I believe the reason MS put the slider in there in the first place was as they've said -- to redirect those extra cpu cycles towards other aspects of the game, besides just the graphics.

And since we're primarily focused on multiplayer issues here, the real point is how it affects the bandwidth required for a session. All you have to do is trace the data being sent from FS to see that it's wasting a tremendous amount of bandwidth when the fps is so high.

QuoteNow, for the part that will probably make some people made...but I just call them like I see them.

Seems that you Russell, and please don't take this the wrong way, but you will cause everyone does..hehe, don't want to admit that something in your program is NOT working properly. But apparently, there are things happening, and it is a new fupah, so NOT your fault, within FS and your program that don't like each other. Since MANY people seem to be having this problem currently, it apparently IS a problem. I do NOT run 2002 games, have it turned off, and have stated such several times on here. So, (and for the record, turning it off was YOUR recommendation long time ago) I get upset when you keep referencing it and making comments that it must be being used. I said it isn't, and that's what I meant.

It sounds to me like you're the one that's mad here, if anyone is. As for my not wanting to admit that something's wrong in my program... I'm not sure I even want to respond to that. But I'll just say that you're welcome to talk to any of my beta testers and ask them about their experience of reporting bugs that they found, and how I responded to them.

QuoteAlso, there is NO reason what so ever, unless the program (fshost) has some issue going on, that we should be forced to connect our clients to it in certain orders. MUST be aux programs (radar, etc..) THEN flight sim, THEN FSnav. Ports must all be different for each client. Very odd and should again NOT be necessary. I run other servers and have 100's of clients that connect to them all using the exact same port, and I use the exact same port with NO problems at all. Yet FSHOst HAS a problem. As I have been running servers for many many years, I can tell you, it IS a problem.

I've never said that they should be connected in a particular order.

And it's been my experience that they don't have to be. But if you're seeing that, then I can only suggest that it's related to how each individual program deals with DirectPlay, and the ports it uses. For example, FSNav uses 23432, which most people don't have open on their routers. When this happens, it gets no response, and switches over to 6073 and 2302-2400. So you could just as easily be using port 1000 or 44000, and the same ports will end up being used. Some routers have a problem with this, and in that case, some people have found that opening port 23432 can help because the entire session will be on one port. Also, some routers open ports automatically, based on which traffic they see going outwards first. This is why you don't have to forward TCP 80 for a web browser, because if the browser makes the initial outgoing connection, the router automatically opens the port for incoming traffic as well. So if a flightsim app was initiating a connection on a particular port, the router might open that port for incoming data, and then other apps that were connected after that might be using ports that were already open. But that's just the general idea -- there's certainly nothing in FSHost that requires that all radar programs be connected before flight sim, etc.

QuoteAgain, may not be your fault, but again, it may be. I don't know, but please don't get so deffensive when we mention that there IS a problem.

I don't remember saying anything defensive -- I thought I was just stating the facts as I know them. And I never said there wasn't a problem, either.

But as I've always said here, I believe the problems you're describing are in DirectPlay, which happens to be used by FS, FSHost, FSNav, and all the other programs that connect directly to a multiplayer session. None of these programs have any control over all of those port issues, other than to select which port (23456, 23432, etc.) is the preferred port if the program wants to connect on a single port without falling back to a random one. It's DirectPlay that handles all of the actual data transfer at the port level, and programs like dplaysvr and dpnsvr are the ones on your system that are deciding which ports to use.

QuoteNow you can yell at me and kick me.....I can take it.

No yelling necessary, but some of your latest posts have come a bit close to crossing the line. So far you've called someone an idiot, and no-doubt offended every FSHost user from one particular country. I'll be editing those posts after I finish with this one (the first time I've ever done that), and I'd appreciate it if you changed your tone a bit on these forums.

Russell

SpectroPro · January 18, 2005, 02:30:04 PM

Never claimed you said things must be done in a certain order. But, if you read the posts on your server here, others have said they had to use exact order, and we also found that they must be done in exact orders or people can't connect.

Also, I never called ANYONE an idiot. When somone posted that they were told that they must do this and that to run your program. I simply stated that those people are idiots. Which, if they claim you must do all that was stated in the post, sorry, but they are idiots. I luckily live in a country where I don't have to be PC. If you wish to ban me for this, fine. Shows that it is other people that have no tollerance. I simply state the facts. Oh, and where did I offend anyone from a country? I mentioned that someone shouldn't go to France. I lived there, and just, again, stating a fact. They shouldn't go there. If that is offensive, then the entire world should be blown up for the things they say about Americans.

On the vision thing, that is an interesting site. My ex-brother in law is an optometrist. I use his info and data for my remarks on that issue. We have talked about this issue several times because of the games issue and magazines making big issues on frame rates of games.

I will definately check out the bw with the frame rates set at various levels. That should be an interesting test. I had not thought of doing that.. But it makes sense. Will collect data on that myself on a couple machines and let you know what I find on this end.

Please, feel free to join us on our Saturday flight. Will be about 1 am Zulu (sunday) or 8pm eastern US time, Saturday Would be great to have you see what happens for yourself on our server. We should have 8-10 people with multiple things connecting that night. hmmm... I hope.