Steam In-Home Streaming Monopolizes Host Computer

[O maestre]

yes and steam should be using remote desktop way of doing its streaming. It is still a remote client connecting as you still need a machine locally at your TV, just not a powerful enough to run the game.

Except it can't do that. What Valve is claiming the SteamOS will do is functionally remote desktop over LAN. Inputs from the steam box or w/e gets sent to the host machine, and the host machine responds with the graphics to display.

Now i dont know where you got the idea that multiple users are not supported on regular versions because i have used it on Pro and corporate editions. And it did not create any clashes as far as im aware. and even if you were right what exactly is making steam nota ble to function in the same manner as, say, the server?

Because it's not?

You can absolutely do remote desktop to pretty much any Windows machine, assuming the network allows it. It does not allow for someone to be using the host machine without conflicts except in server editions of Windows.

The reason it works this way is rather complicated, but the gist of it is that you are confusing Terminal/Server connections with "Remote Desktop". The former is a one-to-many relationship, where one server can handle inputs and commands from N terminals (N being some arbitrary number). It does this by putting the bulk of the processing on the terminal machines and the server predominantly only handling the data I/O to keep it consistent across terminals. There's always exceptions, but that's the general use.

On the other hand, "Remote Desktop" is literally only a remote view of the Windows desktop. It's functionally equivalent to dropping a really long DVI cable from the machine to whatever monitor you happen to be looking at. There's no synchronous multi-user there at all. You can have two people using the same machine that way, but each of their inputs would be fighting against the other's (Especially the mouse) and neither would be able to actually get anything done.

Like I said earlier, you appear to be fundamentally misunderstanding the way computers and Windows in particular operates. What you are insisting they do is definitely possible, but it's not a plausible option for 99.9% of the target userbase.

Actually Teamviewer and some rather malicious worms allow both the host and the remote user to input keyboard and mouse commands concurrently, however the client user has priority to override the host. Teamviewer was designed for people to work simultaneously on either documents or tech support.

 

[cikame]

This was never going to be a huge feature for everyone, it's a useful tool very specific people may want to use if they have the hardware set up to use it, if not it's no big deal.
I have to assume people are getting angry about it here because they don't fully understand.

 

[Agayek]

Actually Teamviewer and some rather malicious worms allow both the host and the remote user to input keyboard and mouse commands concurrently, however the client user has priority to override the host. Teamviewer was designed for people to work simultaneously on either documents or tech support.

That's pretty much exactly what I'm talking about when it comes to "hijacking" the mouse. It's actually quite easy to get a setup where two people can use the same computer at the same time. The issue arises in that the computer can't isolate the inputs to particular windows and, in every case I've ever seen at least, cannot conjure a second mouse cursor for the second person. So what this ends up doing is causing them to fight with each other in order to get things done. It fails miserably when the people involved try to do two different things on the same machine.

If it cant do that, then the fault lies with SteamOS, and should be pointed to appropriately. You know, kinda like how people commented that its silly that they cant do that. because they should. If they want to get any traction they must anyway.
well i guess i am a warlock conjuring magic when i use remote desktop then. Good to know.
the "Default" versions of windows are licese-locked because microsoft is an ass and scream copyright infringement if you try to disable the artificial limitation of singlesession connections. That does not have to apply to steamOS. in fact it shouldnt be an issue to begin with considering SteamOS is to be free of charge.
You initiate a seperate session for each profile that logs in and you can use multiple people on a single computer.

It's not a problem with SteamOS, it's a problem with the way Windows operates. It's a fundamental design decision of the OS (and just about every other OS for that matter). The vast majority of customer-facing OSes are designed specifically for one active task/process at a time. This means that, for reasons I've already outlined, they can't support concurrent users doing two different things. The only big exception to this is a server architecture that's specifically designed to support multiple users.

As for Remote Desktop, no, you're not using magic. I'm going to take a stab at the situation in which you use Remote Desktop from what you've said and implied: It sounds like at work you're either using a Mac/Linux box and need Windows functionality from time to time or you use it to collaborate with someone.

Neither of these have much of anything to do with Remote Desktop, really. As I've said before, RD is functionally equivalent to plugging another monitor and KB+M into the host machine. From a purely functional standpoint, there is absolutely no difference between them, except for the possible distances the second monitor can be from the host.

There's plenty of things ranging from annoying to bad in the SteamOS (not least of which is the fact that this kind of streaming is almost certainly going to be widely required for the first couple years at least), but locking down the host computer while streaming games is not one of them. It's a limitation of existing computational platforms, and there's nothing Valve can actually do about it without hiring an IT professional for every single one of their customers to set up the environment for them.

 

[Strazdas]

Actually Teamviewer and some rather malicious worms allow both the host and the remote user to input keyboard and mouse commands concurrently, however the client user has priority to override the host. Teamviewer was designed for people to work simultaneously on either documents or tech support.

That's pretty much exactly what I'm talking about when it comes to "hijacking" the mouse. It's actually quite easy to get a setup where two people can use the same computer at the same time. The issue arises in that the computer can't isolate the inputs to particular windows and, in every case I've ever seen at least, cannot conjure a second mouse cursor for the second person. So what this ends up doing is causing them to fight with each other in order to get things done. It fails miserably when the people involved try to do two different things on the same machine.

If it cant do that, then the fault lies with SteamOS, and should be pointed to appropriately. You know, kinda like how people commented that its silly that they cant do that. because they should. If they want to get any traction they must anyway.
well i guess i am a warlock conjuring magic when i use remote desktop then. Good to know.
the "Default" versions of windows are licese-locked because microsoft is an ass and scream copyright infringement if you try to disable the artificial limitation of singlesession connections. That does not have to apply to steamOS. in fact it shouldnt be an issue to begin with considering SteamOS is to be free of charge.
You initiate a seperate session for each profile that logs in and you can use multiple people on a single computer.

It's not a problem with SteamOS, it's a problem with the way Windows operates. It's a fundamental design decision of the OS (and just about every other OS for that matter). The vast majority of customer-facing OSes are designed specifically for one active task/process at a time. This means that, for reasons I've already outlined, they can't support concurrent users doing two different things. The only big exception to this is a server architecture that's specifically designed to support multiple users.

As for Remote Desktop, no, you're not using magic. I'm going to take a stab at the situation in which you use Remote Desktop from what you've said and implied: It sounds like at work you're either using a Mac/Linux box and need Windows functionality from time to time or you use it to collaborate with someone.

Neither of these have much of anything to do with Remote Desktop, really. As I've said before, RD is functionally equivalent to plugging another monitor and KB+M into the host machine. From a purely functional standpoint, there is absolutely no difference between them, except for the possible distances the second monitor can be from the host.

There's plenty of things ranging from annoying to bad in the SteamOS (not least of which is the fact that this kind of streaming is almost certainly going to be widely required for the first couple years at least), but locking down the host computer while streaming games is not one of them. It's a limitation of existing computational platforms, and there's nothing Valve can actually do about it without hiring an IT professional for every single one of their customers to set up the environment for them.

You do make fair points and i have to end up agreeing with you there.
A few others thins to clarify, all machines i use are windows run and we do collaborated in my said situation of remote desktop but the collaboration was silent, i would be editing open file, other guy another, at the same time. we were programming a game server.... well... programming is a bit strong word i guess.... more like modding....., mostly xml and lua based codes is what i did.
Now i do have a question, there are some games where if you alt-tab and start browsing - the mouse and eyboard still clicks on the gamei tself (which often results in hilarity unless you use pause and dont click pause button while browsing, so the game is aweare of its own problems). They somehow manages to make inactive widow reach like active, how do they do that?

 

[Agayek]

Now i do have a question, there are some games where if you alt-tab and start browsing - the mouse and eyboard still clicks on the gamei tself (which often results in hilarity unless you use pause and dont click pause button while browsing, so the game is aweare of its own problems). They somehow manages to make inactive widow reach like active, how do they do that?

That comes down to the way Windows handles user inputs and how the game itself processes those events. Basically, when the user moves the mouse or presses a key or whatever, the following happens:

1) Input device sends a signal to Windows.
2) Windows' kernel (the lowest and closest to hardware software layer) processes the signal and determines what the input is (specifically, the device that generated it and the specifics of the input, ie what letter on the keyboard, new position for the mouse cursor, etc)
3) The kernel sends a signal informing the OS layer about the input
4) The OS layer processes the signal and creates what's known as an "event" that will be sent to any/all processes that have registered themselves to be alerted
5) The applications react to the event in whatever manner is appropriate

In the case that you're talking about, what happens is that the game registers as a listener for input events (read: asks to be alerted whenever an event occurs), and when it gets tabbed out, it fails to un-register itself and so it still receives input events.

Basically, what happens is that visible programs are supposed to only be registered for input events when they're "Active" (read: selected and displaying to the user), but not every program is coded to do so, for whatever reason. The predominant reason is because, in the dev's mind, you're not supposed to look at something outside of the game without closing it. That's the only reason I can think of to do that anyway.

 

[Strazdas]

snip

I see. Thanks for the explanation.