20,741
edits
FlightGear WorldTerrain SkyBox Server: Difference between revisions
Jump to navigation
Jump to search
m
FlightGear WorldTerrain SkyBox Server (view source)
Revision as of 04:30, 5 March 2015
, 5 March 2015→Networking
m (→Approach) |
m (→Networking) |
||
| Line 341: | Line 341: | ||
== Development == | == Development == | ||
My suggestion would be to introduce 2-3 well-defined layers/components here: 1) the screen shot/image handling stuff, 2) the IPC/RPC layer, 3) the retrieval method (which could also be IPC based at some point). | |||
=== Networking === | === Networking === | ||
Your current implementation looks like a telnet-like approach to me - so, you could just as well modify the existing built-in telnet protocol/daemon to add support for new "skybox" related commands there - I've added corresponding pointers to the article on doing just that. I did something pretty much like that a few years ago, and it was really dead-simple. | |||
I am not saying that this is necessarily the way to keep this working - but for the sake of prototyping, I would definitely focus on extending the built-in telnet daemon/server first. | |||
We already have an RPC mechanism built-on top of so called "fgcommands" - those can also be easily invoked via telnet. | |||
Which basically means that telnet can be used for arbitrary IPC, and fgcommands can be used for creating/extending functionality. | |||
Equally, we already have a httpd-based jpeg-server that serves screen shots using native OSG machinery. | |||
In other words, your current approach could be easily simplified and generalized, so that it would also become more efficient/faster. | |||
I would probably continue prototyping, but on top of the built-in telnet protocol. | |||
That will greatly simplify your code - once you need something more powerful, e.g. for also serving binary data (think image blobs), I would consider adding a custom I/O protocol. I can tell you exactly how to do that and also provide stubs to get you going quickly, including all the cmake magic to integrate things properly. But I would prefer using telnet for starters, to move away from your current hard-coded I/O approach. | |||
There's cross-platform/multi-platform socket handling code in simgear for all the socket stuff you are doing there e.g. see [http://api-docs.freeflightsim.org/simgear/classSGSocket.html SGSocket] Internally, I/O protocols and network stuff usually live in $FG_SRC/Network | There's cross-platform/multi-platform socket handling code in simgear for all the socket stuff you are doing there e.g. see [http://api-docs.freeflightsim.org/simgear/classSGSocket.html SGSocket] Internally, I/O protocols and network stuff usually live in $FG_SRC/Network | ||
Which is also where you can see, that there's the concept of an "FGIOChannel" for encapsulating all the logic you added to fg_init.cxx | Which is also where you can see, that there's the concept of an "FGIOChannel" for encapsulating all the logic you added to fg_init.cxx | ||