Problem Winsock issue

[dumbo2007]

Hi,

I am trying to send data out of Orbiter using a plugin, to another application. I am using Winsock. The plugin is a class derived from oapi::Module and I overload the required functions like clbkPreStep(). In the constructor of this class I launch a thread that transmits data using send() to a simple client in the same computer.

The plugin is loaded correctly when I start the launchpad and select it. It sends data continuously till I decide to launch a scenario. After launching a scenario data is sent for about 10 times until it suddenly fails. The receive in the client is a blocking call and accordingly blocks waiting for data from the plugin inside orbiter. I am using a bare bones server in the plugin and also a very simple client. There is no blocking due to firewall etc as data would not have begun going through if that were the case.

I am suspecting that the Winsock system is somehow affected after a scenario launch. Has anyone else ever faced such an issue ?

 

[Hielor]

Hi,

I am trying to send data out of Orbiter using a plugin, to another application. I am using Winsock. The plugin is a class derived from oapi::Module and I overload the required functions like clbkPreStep(). In the constructor of this class I launch a thread that transmits data using send() to a simple client in the same computer.

The plugin is loaded correctly when I start the launchpad and select it. It sends data continuously till I decide to launch a scenario. After launching a scenario data is sent for about 10 times until it suddenly fails. The receive in the client is a blocking call and accordingly blocks waiting for data from the plugin inside orbiter. I am using a bare bones server in the plugin and also a very simple client. There is no blocking due to firewall etc as data would not have begun going through if that were the case.

I am suspecting that the Winsock system is somehow affected after a scenario launch. Has anyone else ever faced such an issue ?

Have you tried using Orb:Connect? It doesn't have this problem and was been fairly extensively developed/tested. I imagine it would be a lot easier to just use that than to write your own server...

 

[dumbo2007]

Thanks for the tip. I am not exactly exporting Orbiter data though. I am trying to integrate the Bullet physics engine into Orbiter. At the moment I have not integrated vessels in Orbiter but I have got simple objects moving around in the physics world(simply world from now on).

I want to make a viewer for the world. So if a ship in Orbiter is represented by a sphere inside the physics world, then I should be able to see where it is in a co-ordinate system.

So I tried to export the data from Bullet to an external opengl viewer application through Winsock. Bullet running inside Orbiter is the Server and the viewer is the client. However after the first few values were sent...about 10...the server stops transmitting. So i decided to dump Winsock and use Shared Memory instead. Shared Memory works perfectly and is supposed to be the fastest method of IPC among processes in the same computer.

So now I have a plugin whose main thread runs the physics engine in the
clbkPreStep(double SimT, double SimDT, double MJD) overridden method

The engine simulates 2 balls colliding. The physics simulation starts running only after a orbiter scenario is launched. A second thread is started after the plugin is loaded in the launchpad which launches an Opengl window immediately to show the 2 balls in 3D. Since the clbkPreStep() override is not called till a scenario is started in orbiter, the engine does not start moving the balls till then.

I also tried to code the engine inside a vessel class by overriding its clbkPreStep method. Here I launched a separate thread for the Physics engine and viewer combined. So in the event loop of opengl, I would call a Bullet function to update the sim and then update the display. This allowed very high speeds...to the point where i had to slow down the simulation to 1/10th speed to make sure I could see things happening.

So now I am considering which approach to use finally...to use a separate thread for the viewer or to have it as a separate app...and send data via shared memory