Meadville Space Center
Welcome, Guest. Please login or register.
January 22, 2021, 02:19:58 PM

Login with username, password and session length
Search:     Advanced search
Project Apollo Beta 7.0 released!
http://nassp.sf.net/wiki/Installation
25068 Posts in 2094 Topics by 2266 Members
Latest Member: Apollo Next
* Home Help Search Login Register
+  Meadville Space Center
|-+  Project Apollo - NASSP
| |-+  Project Apollo - NASSP Development
| | |-+  Programming (Moderators: movieman, dseagrav, Swatch, lassombra)
| | | |-+  Telcom Bind() Failed.
« previous next »
Pages: [1] Print
Author Topic: Telcom Bind() Failed.  (Read 2640 times)
lassombra
Moderator
Sr. Member
****
Posts: 410


View Profile Email
« on: December 16, 2007, 01:35:00 AM »

I know it's been said that the source of this problem is that Orbiter doesn't properly reinitialize stuff when it opens again from the launchpad (without totally exiting).  I set about trying to understand the problem further, and I've come to the conclusion that it isn't initializing properly, as obviously we are getting the opportunity to initialize the Telcom, but rather that we aren't successfully detecting the drop to launchpad and CLOSING the socket.

Is it just that I'm totally off my rocker? or does this make some sense to someone?

I know this has mostly been disregarded as an orbiter limitation, but I think it should be more considered a bug and I think I might be close to stomping it.
Logged

My current Project Apollo work:

Quickstart to the Moon initiative (Quickstart_to_the_Moon): Done through earth orbit.  Working on new method of calculating TLI.

Checklist Controller: 
  • MFD Interface 99%(Minor cleanup and future features remain)
  • Panel Interface 99%
  • Excel interface and logic 99%
  • LEM Event code.0%
  • DSKY Interface code. Framework complete, creating "buttons"
  Approximately 80% done. (Checklist Controller
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
*****
Posts: 3700


nassp.sf.net


View Profile WWW
« Reply #1 on: December 16, 2007, 01:31:08 PM »

Yes, the problem is that ovcExit isn't called (and thus the destructor etc.) with Orbiter's default shutdown settings. I wonder if we can handle the socket stuff in the ProjectApolloConfigurator provided that opcCloseRenderViewport is still called. The Saturn can communicate with the ProjectApolloConfigurator by using the GetModuleHandle/GetProcAddress win32 API functions, this is already in use in Saturn::clbkLoadPanel in order to determine if the render viewport is widescreen, so perhaps the Saturn could get the socket (or whatever necessary) from the ProjectApolloConfigurator and the configurator closes open stuff in opcCloseRenderViewport...

Cheers
Tschachim
Logged

movieman
Moderator
Hero Member
****
Posts: 1710



View Profile
« Reply #2 on: December 16, 2007, 02:19:52 PM »

Is the DLL unload function called? If so, we could handle socket shutdown there.
Logged
lassombra
Moderator
Sr. Member
****
Posts: 410


View Profile Email
« Reply #3 on: December 16, 2007, 05:13:12 PM »

DLL unload is only called after exiting from the launchpad.

The problem is we need to detect dropping to the launchpad properly.  It seems the only way to do this properly would be to, as you say, register with the class with the configurator so that it can then perform the functions required.  Actually, we'd just have to register the telcom classes with it.  I'll try today to put something together.
Logged

My current Project Apollo work:

Quickstart to the Moon initiative (Quickstart_to_the_Moon): Done through earth orbit.  Working on new method of calculating TLI.

Checklist Controller: 
  • MFD Interface 99%(Minor cleanup and future features remain)
  • Panel Interface 99%
  • Excel interface and logic 99%
  • LEM Event code.0%
  • DSKY Interface code. Framework complete, creating "buttons"
  Approximately 80% done. (Checklist Controller
movieman
Moderator
Hero Member
****
Posts: 1710



View Profile
« Reply #4 on: December 16, 2007, 05:24:44 PM »

If the DLL isn't unloaded, then surely all the code can be handled there through some global variables and functions?
Logged
lassombra
Moderator
Sr. Member
****
Posts: 410


View Profile Email
« Reply #5 on: December 16, 2007, 06:15:37 PM »

That might be possible, at least making the SOCKET a global variable.  The catch would be when initializing we'd then have to test if the socket was already initialized or not.

I think the initialization still should happen as normal and have an instruction to test if the socket is already open.

I'm working on a couple versions of the code and we'll see how it comes.  The one I'm leaning toward is registering the telcom with the configurator and depending on it to tell us that the viewport has closed so we can deinitialize. 
Logged

My current Project Apollo work:

Quickstart to the Moon initiative (Quickstart_to_the_Moon): Done through earth orbit.  Working on new method of calculating TLI.

Checklist Controller: 
  • MFD Interface 99%(Minor cleanup and future features remain)
  • Panel Interface 99%
  • Excel interface and logic 99%
  • LEM Event code.0%
  • DSKY Interface code. Framework complete, creating "buttons"
  Approximately 80% done. (Checklist Controller
lassombra
Moderator
Sr. Member
****
Posts: 410


View Profile Email
« Reply #6 on: December 17, 2007, 04:14:40 AM »

Ok, going with globals just breaks stuff on the second run (no real surprise).

I didn't change much, but it didn't take much.  The other option which I'm working on coding up is to pass a reference to the socket to the configurator or the MFD (both should receive the call to the close function)

Once that is done, it should be a small matter to close the socket.
Logged

My current Project Apollo work:

Quickstart to the Moon initiative (Quickstart_to_the_Moon): Done through earth orbit.  Working on new method of calculating TLI.

Checklist Controller: 
  • MFD Interface 99%(Minor cleanup and future features remain)
  • Panel Interface 99%
  • Excel interface and logic 99%
  • LEM Event code.0%
  • DSKY Interface code. Framework complete, creating "buttons"
  Approximately 80% done. (Checklist Controller
lassombra
Moderator
Sr. Member
****
Posts: 410


View Profile Email
« Reply #7 on: December 17, 2007, 04:27:23 AM »

I've put the code necessary to close the socket into the project apollo MFD (I don't know if it's necessary, but the documentation only says plugin, and I'm just not sure that the configurator falls into that, it could though, I don't know.)

Either way, that's where I put the code, and I had to update the VC2005 project file to link to WS2_32.lib so that it would link properly.

I don't have the program available to update the other project files.  So, if whoever does could do so, it'd be appreciated.

I'm finalizing some code, and then we'll test.  Basically, all it's doing is passing the socket itself to the MFD which is then closing the socket when dropping to launchpad.
Logged

My current Project Apollo work:

Quickstart to the Moon initiative (Quickstart_to_the_Moon): Done through earth orbit.  Working on new method of calculating TLI.

Checklist Controller: 
  • MFD Interface 99%(Minor cleanup and future features remain)
  • Panel Interface 99%
  • Excel interface and logic 99%
  • LEM Event code.0%
  • DSKY Interface code. Framework complete, creating "buttons"
  Approximately 80% done. (Checklist Controller
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
*****
Posts: 3700


nassp.sf.net


View Profile WWW
« Reply #8 on: December 17, 2007, 07:05:37 AM »

Yes, the ProjectApolloConfigurator is a plugin, too, and I strongly suggest to use the configurator instead of the MFD because the user can disable the MFD (and so messing it up), but not the configurator.

I can do the project file changes, no problem.

Cheers
Tschachim
Logged

lassombra
Moderator
Sr. Member
****
Posts: 410


View Profile Email
« Reply #9 on: December 17, 2007, 09:09:25 AM »

Hmm.... Decision time, I suppose I can use the configurator (it's not really that difficult to change at this point)

but I've noticed some other errors and am putting quite a bit of debug data into another program on the MFD.  Perhaps a solution would be to go ahead and pass the socket to the MFD (as I already am doing) but also to the Configurator, allowing the Configurator to do the close action, but giving the MFD the info (which I'm currently using for more than just shutting down cleanly, which I think I now have working properly).

Also...

I've found a bug in my testing of my new code, and I don't believe the bug is associated with my code as I've found it also in the pack I built to release.  The bug seems to be related to the saving/loading of the AGC.

I load the Apollo 7 launch scenario from the vAGC folder.  I can connect the telemetry client no problem.  I can disconnect and reconnect freely.  Thus the program is working as intended.  Pretty much regardless of what I do to it, I get data to the client.  Then, I turn on the CMC.  This is where things start to get hairy.  The telemetry client will continue to run at this point, and I can interface with the dsky from the client (uplink).  This is all good and well, but once I exit orbiter (and yes, I completely exit) and reload the (current state) scenario, I no longer am able to get data to the client.  I am no longer able to interface with the computer.  And when I do disconnect the client, I am unable to reconnect.  This problem appears to be happening independent of my code, so I'm going to procede.

[EDIT: After much (almost a minute) deliberation, I have decided that I'm going to implement this functionality into the MFD AND the Configurator.  The configurator will handle closing the socket, but the MFD will now also receive the socket info allowing us to view debugging data that may come in handy.  I'll have all relevant items committed later today.]
« Last Edit: December 17, 2007, 09:14:43 AM by lassombra » Logged

My current Project Apollo work:

Quickstart to the Moon initiative (Quickstart_to_the_Moon): Done through earth orbit.  Working on new method of calculating TLI.

Checklist Controller: 
  • MFD Interface 99%(Minor cleanup and future features remain)
  • Panel Interface 99%
  • Excel interface and logic 99%
  • LEM Event code.0%
  • DSKY Interface code. Framework complete, creating "buttons"
  Approximately 80% done. (Checklist Controller
lassombra
Moderator
Sr. Member
****
Posts: 410


View Profile Email
« Reply #10 on: December 17, 2007, 10:11:44 AM »

Ok, the fix is committed.  If you are using VC2005, it should compile straight away, as I committed the updated project files for that as well.  If you are using VC2003 or 2008, please update your project files for the CONFIGURATOR and the MFD to link WS2_32.lib.  This gives us access to the winsock functions in those two modules, the configurator to close the socket solving our long existing TELECOM: Bind() Failed problem, and the MFD to display debug data about the socket.
Logged

My current Project Apollo work:

Quickstart to the Moon initiative (Quickstart_to_the_Moon): Done through earth orbit.  Working on new method of calculating TLI.

Checklist Controller: 
  • MFD Interface 99%(Minor cleanup and future features remain)
  • Panel Interface 99%
  • Excel interface and logic 99%
  • LEM Event code.0%
  • DSKY Interface code. Framework complete, creating "buttons"
  Approximately 80% done. (Checklist Controller
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
*****
Posts: 3700


nassp.sf.net


View Profile WWW
« Reply #11 on: December 17, 2007, 03:27:50 PM »

I tried the fix, but in order to get it working with VC6 I'd need to remove all occurrences of "__stdcall", otherwise it's crashing. The "__stdcall" thingy is something I copied from the Meshland/CollisionSDK interface without really understanding it, but the Meshland Dll's are written in Pascal, this might be the difference. Now I would like you to test if its still working in VS 2005 if you remove "__stdcall" and if yes, commit the change, I didn't change anything to avoid confusion.
Also you might consider to move "registerSocket" to the PCM class, that would look more clearly in my opinion.  Happy

Cheers
Tschachim
Logged

lassombra
Moderator
Sr. Member
****
Posts: 410


View Profile Email
« Reply #12 on: December 17, 2007, 03:58:30 PM »

Interesting, I've never heard of the __stdcall causing a problem.  Yes it is pascal strictly speaking, but it is part of the microsoft C++ standard...  It is the accepted way to call microsoft API functions that have been loaded dynamically (runtime instead of load time).

Personally though, I'm surprised there is any problem, unless it is the use of arguments.  The reason I say that is the Saturn has had __stdcall in it since before I was a real member of this team.

Microsoft provides two functions for this operation, __stdcall, and __cdecl.  __stdcall does not incorporate stack cleanup, and expects the receiving function to do so.  __cdecl incorporates it's own stack cleanup code.  Strictly speaking __cdecl is probably the correct choice, but like I said, I'm surprised it even matters since we were using __stdcall with no problems.  I will change it to __cdecl and see what happens.

Ok, I committed that, if someone can test it in VS2003 that would be great, as I can't do so.  Also something to note, since __cdecl has it's own internal stack cleanup code, I was able to pretty easily call the MFD code from within the configurator, leaving us with simpler code in csm_telecom.cpp and also making it pretty safe against future errors.
« Last Edit: December 17, 2007, 04:51:58 PM by lassombra » Logged

My current Project Apollo work:

Quickstart to the Moon initiative (Quickstart_to_the_Moon): Done through earth orbit.  Working on new method of calculating TLI.

Checklist Controller: 
  • MFD Interface 99%(Minor cleanup and future features remain)
  • Panel Interface 99%
  • Excel interface and logic 99%
  • LEM Event code.0%
  • DSKY Interface code. Framework complete, creating "buttons"
  Approximately 80% done. (Checklist Controller
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
*****
Posts: 3700


nassp.sf.net


View Profile WWW
« Reply #13 on: December 17, 2007, 05:07:07 PM »

Now it's working fine (with VC6, too), thanks for fixing that bug!  Thumbs Up

Cheers
Tschachim
Logged

lassombra
Moderator
Sr. Member
****
Posts: 410


View Profile Email
« Reply #14 on: December 17, 2007, 05:10:45 PM »

Happy to do so... Trust me, that bug was driving me wild while I was working on the quickstart to the moon checklist (when you have to close and type every half hour or so, you don't want to have to remember to totally exit orbiter!)

A side affect of fixing this bug is we now have access to more complete information on the telecom's status through the MFD (it passes the socket, but we can use that and the winsock functions to get just about any data needed).  I left it pretty bare bones, right now it just displays the numeric identifier for the socket.
Logged

My current Project Apollo work:

Quickstart to the Moon initiative (Quickstart_to_the_Moon): Done through earth orbit.  Working on new method of calculating TLI.

Checklist Controller: 
  • MFD Interface 99%(Minor cleanup and future features remain)
  • Panel Interface 99%
  • Excel interface and logic 99%
  • LEM Event code.0%
  • DSKY Interface code. Framework complete, creating "buttons"
  Approximately 80% done. (Checklist Controller
Pages: [1] Print 
« previous next »
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.10 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!