Project OGLA Linux Thinclient proof of concept

[Artlav]

Following the discussion about Orbiter on Linux and requests from simpit makers gets to the serious attempts to make some practical use out of the fact that OGLAClient can run natively on Linux.

Here is the proof of concept for the thin graphics client:
orbides.1gb.ru/orbf/ogla_thinclient_poc_090413.zip Current in post #6
(For beta 090331)

What is it?
It is a set of 3 programs -
1. OGLAClient server, an Orbiter add-on that broadcasts Orbiter graphics client interface to the clients connected to it by TCP/IP.
2. OGLA thin client for Windows - an graphics TCP/IP client to be connected to [1].
3. OGLA thin client for Linux, same as [2].

To run - Run Orbiter_ng, activate the OGLAClient_server module, run.
Then, ./oglathin <server_name> runs the client part. If server is not specified, localhost is used.
oglathin - linux version, oglathin.exe - Windows version.

What is it supposed to do?
[1] is basically a barebone graphics client that does no graphics, but wraps and sends OGLAClient scene over the network to the Client connected to it.

Since it's a proof of concept, don't expect much - it barely scratches the surface now.
System configuration and planets, sun and camera state vectors is all that is being sent now, and there is no way for remote input (probably no way at all for it).

Why?
One scheme is presented above - run Orbiter under WINE or some kind of VM, and let the platform-independent graphics part connect to it over the local network, thus allowing to run it with native performance.

Second scheme, one to be developed, is to have a server running on a big PC, while a bunch of thin clients on weak PC's will show the image and MFD's on multiple screens, like simpit.
With some work it would be able to transmit MFD's separately, or even run as graphics on main system, transferring MFD's otherplace.

Why there is nothing of these niceties in the actual file?
Because it's in the beginning of being developed now.

So, why release it?
To show, that it could be done, and to ask everyone interested to do it, to try if the said schemes (Wine-native, or Win machine-LAN-linux machine) actually works, since i was unable to test the Linux part properly yet, and won't be able for a short while.

Also, any ideas are welcome.
Consider it as open project - Linux, Windows, Network, OGLA engine.
What do you want to see being made out of these?

--- Post Added ---

An all-important update:
orbides.1gb.ru/orbf/ogla_thinclient_poc_090414.zip Current in post #6
EDIT: Fixed the link

This time, i was able to check the thing out, consequently:
*Fixed address parameter passing, now it can connect remotely.
*Fixed Linux version into a working state
*Fixed rendering artefacts, haze, vessels
*Fixed network fall-outs problems
*Fixed state vectors inconsistencies

Bug reports, ideas and opinions are welcome.

 

[spec10]

I was gonna write a post about how I like this thread because it's about a realistic solution, not some wishful thinking or something based on unfunded assumptions ... well I won't do that p) but instead i write this:

That approach is awesome.

 

[TSPenguin]

In order to keep the network load clean, how about using UDP for the one way data and TCP for keypresses, clicks etc. ?

 

[Artlav]

In order to keep the network load clean, how about using UDP for the one way data and TCP for keypresses, clicks etc. ?

I'm not sure if it's worth the trouble, since the main usage is the local networks, not over-the-internet.

What is better - one 4kb TCP send or a half-hundred 50 byte UPD datagrams?
Anything smaller than a couple state vectors per datagram, and there will be some serious need for consistency checks, as far as i understand the way UDP works.
And, it's not like streaming media - errors cannot be tolerated here.

 

[TSPenguin]

A UDP datagram can be much larger than 50 Byte. You should be able to squeeze everything in there you need as you have ~62KB space.
Since we are talking live telemetry (in a way) it makes little sense for the client to rerequest data which is outdated anyway. I'd rather have the view spasm out for a frame than a much worse internet performance.
And I disagree with no toleration of errors. Afterall, it is just supposed to be a render client. For everything going back to the simulation you need to be error free, so UDP is not a choice there.
Of course this is primarily used localy. But implementing a live video feed(render) in mission control a continent away is worth using UDP.
[/2cents]

 

[Artlav]

Update #2:
http://orbides.1gb.ru/orbf/ogla_thinclient_poc_090414_1.zip
*Added state smoothing, the temporary positions are propagated locally, allowing smooth video even with 2 sends/s.
*Cleared up some residue

A question into the void:
-How can a program under UNIX system request files non-case sensitive?
There are a lot of files in Orbiter install, and most of them are in random case, making lots of problems.

A UDP datagram can be much larger than 50 Byte. You should be able to squeeze everything in there you need as you have ~62KB space.

Can it arrive in pieces? Or do it guarantee, that a packet will not be split? I mean, not by design, but in real practical use?

In case of TCP, the packets arrive split in about 1-4kb pieces, and the client have to put them together. If there will be the same thing with UDP, but with lost and out-of-order packets, it's not worth the trouble.

Since we are talking live telemetry (in a way) it makes little sense for the client to rerequest data which is outdated anyway. I'd rather have the view spasm out for a frame than a much worse internet performance.

Makes sense... The spasmics are solved easily, but high data rate is still preferable.

Of course this is primarily used localy. But implementing a live video feed(render) in mission control a continent away is worth using UDP.

Video? Few kb's of state vectors and drawing commands per frame, not a live video feed.
Or did you mean just the fact of it?
Still, it's technically, just a very tight fractal image compressing.

 

[TSPenguin]

Video? Few kb's of state vectors and drawing commands per frame, not a live video feed.
Or did you mean just the fact of it?
Still, it's technically, just a very tight fractal image compressing.

I meant the fact of it. It will be a render of the send data.

Regarding the UDP fragmentation, I don't know. Maybe someone here will.
It would make sense that the IP stack assembles the packet before handing it off to the application though.

 

[garyw]

There are several different answers to your question depending on what level you're worried about.

At the app level you don't need to worry about fragmentation in the sense that you will never receive a partial packet. The networking stack will take care of reassembling fragmented UDP packets for you. The reason why you care about fragmentation at all is to minimize the chance the stack will give up on delivering the packet because of lost fragments.

At the IP level the various RFC's demand that the networking stack be able to send/receive a (IPv4) packet of the aforementioned 576 bytes. Note that this is the total size of the packet including IP and UDP headers so the actual amount of data you can send is a bit less. The stack *could* fragment packets that are bigger. Usually though you can go quite a bit bigger before you get into trouble at this level.

People often talk about the minimum MTU (maximum transmission unit) and this usually has to do with the networking layer below IP - ethernet or whatever. The number that gets thrown around here is 1500 (again this is total size including ethernet/IP/UDP headers as well as app data). It's possible for the packet to be fragmented at this layer without the knowledge of the higher layers (e.g. ATM's 53-byte packets...).

In my experience people usually go with the 1500 number.

 

[Artlav]

Now that changes a lot.

Next problem: What about NAT's?
If the client PC is behind a NAT, the server can't back-connect a UDP socket.
Or is it a minor problem?

 

[Zatnikitelman]

NAT works automatically on Layer 3 of the OSI model. Since NAT can only really be handled at this layer and this layer is really only implemented on routers (honest to goodness ones and consumer ones) the network will handle the NAT by itself.
The UDP packet gets a frame put on it by the client NIC, the router will strip the frame off and put a new destination frame around the packet. In NAT, the process is a little deeper, the packet has to be slightly altered so that although external clients will see the public IP of the network, the NAT-ing router will see the change and route accordingly.
So in short, NAT should be handled automatically.

 

[Artlav]

The problem is, that it doesn't work in practice.
Or i don't know how to do it.

If a client behind a NAT connects to the server, server gets UDP packets, the client don't.
If a server back-connects to the client following the TCP connect established prior, packets don't go either way.
On a static ip set, everything works.

Anyone know where to find a practical how-to on these things?

 

[Zatnikitelman]

That's what port forwarding is used for. It isn't a complete solution and NAT isn't the best system, but if something didn't work, then I couldn't host or play Halo Trial games for example since it uses UDP as well as TCP. So users would have to manually open the ports (or allow all traffic through, but not a good idea) but they do that any ways for games like Halo and such.

 

[TSPenguin]

The best would be to make it like skype.
UDP punching works very well and does not require the user to make any configuration.
How well this is applicable for your needs depends. In theory, if you can make a TCP connection, you don't even need this for UDP anyway.
A good article on Heise security describes the process very well: http://www.h-online.com/security/How-Skype-Co-get-round-firewalls--/features/82481/0

 

[cjp]

A question into the void:
-How can a program under UNIX system request files non-case sensitive?
There are a lot of files in Orbiter install, and most of them are in random case, making lots of problems.

AFAIK there is no standard function for that. In fact, such a function could have undefined behavior in some cases in UNIX, e.g. when there are multiple files with names that only differ in their case.

You can make a function for doing this. What you can do is to search directory contents manually, using functions like opendir (read its manual page on how to use it).

But this problem sounds so common that there must be someone who has already done that. If you don't want to do it, just look for some open source project that's likely to include a solution. I know Wine has it, but Wine is a huge project and maybe you don't want to search for code in it.

 

[insanity]

There is a pretty cheap way to do it as indicated here: http://www.lynchconsulting.com.au/b.../Noncase-sensitive-filesystem-on-Linux--HOWTO

I haven't had a chance to run a test on the method yet, so I don't know how applicable it could be to this situation.

 

[sunshine135]

Why worry about NAT/PAT?

The problem is, that it doesn't work in practice.
Or i don't know how to do it.

If a client behind a NAT connects to the server, server gets UDP packets, the client don't.
If a server back-connects to the client following the TCP connect established prior, packets don't go either way.
On a static ip set, everything works.

Anyone know where to find a practical how-to on these things?

Artlav. Why would you worry about NAT? My understanding of your proof of concept was to render on machines over a LAN. This would be how a simpit is built. You really only have to worry about NAT if you are going out to a WAN off a network with many clients and a single, static IP address. I don't believe you would do this. Most people don't go so far as to NAT anyhow. That is more of a business or office network model to connect to remote offices.

 

[TSPenguin]

Most people don't go so far as to NAT anyhow. That is more of a business or office network model to connect to remote offices.

Are you aware that most people these days use a router at home? They are all using NAT to access the internet.

 

[sunshine135]

MJR LOL

Are you aware that most people these days use a router at home? They are all using NAT to access the internet.

I understand this. My question was simply based on the proof of concept, what is the ultimate goal? My take is that this was for a client/server model for a simpit setup utilizing a Linux/Windows network. What would be the reason we would want to use this particular proof of concept over a WAN?

 

[TSPenguin]

Are you aware that most people these days use a router at home? They are all using NAT to access the internet.

I understand this. My question was simply based on the proof of concept, what is the ultimate goal? My take is that this was for a client/server model for a simpit setup utilizing a Linux/Windows network. What would be the reason we would want to use this particular proof of concept over a WAN?

I wasn't answering your question.
But let me try now.

The reasons are the same as any other networked rendering.
Having live video for mission control with out the need for overly strong hardware to encode a video and without the need for the huge amounts of bandwidth that regular video needs.

 

[sunshine135]

The only issue you have is if a source IP address is in the actual data payload of your application. NAT has no capability of replacing IP addressing in your data. To make this function properly, you would need to enable an application layer gateway function. Also, NAT adds performance overhead to the application, but it appears that this is the main purpose of said Thinclient. Somehow, I do not believe these will be issues unless there is some plan to stream data in special codecs (for instance, in VoIP, we can't use H.323 in NAT, so we don't use it.)

If this is not an issue, the end user may only have to tweak some QoS settings to give the Orbiter application/ports a higher priority over normal data to improve throughput. This may be helpful for users with lower bandwidths also. I believe most home routers enable you to specify this to the port level too.

Rendering the video locally is a great way to prevent high data overhead (I think this was mentioned before), this way you only have to transmit enough data to update/ refresh the state of the display.

Hope this is helpful!!!