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