The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Dumb thought re. web apps

(WARNING: I'm mainly an embedded developer & don't know much about web apps). You don't hear much about SSH + X for web apps, as an alternative to the kludgy mess we have now (HTML + cookies + Javascript + DHTML + Flash + God knows what else). I wonder why? It seems like a natural. There are X servers for Windows boxes, I've seen them. Has anyone ever seen discussions of this in print?
John Foxx
Sunday, May 01, 2005
 
 
Even better than X, RDP. Indeed, it's kinda pathetic to have to jump through so many hoops with web apps when there are much better alternatives available.
Fred.
Sunday, May 01, 2005
 
 
Thin clients, and the ability to transmit the windows drawing commands across a net connection was built into windows XP from day one. This is the same idea as x-windows. The so called RDP (remote desktop protocol) that is built into windows XP is the same technology that Citrix/Windows terminal services is based on. This system provides the use of the desktop from any other computer connected on the net.

There is number of reasons why companies like Microsoft did not make thin client their strategy (despite the fact that RDP is shipped with every copy of windows).

You can read about my thoughts on this issue here:

Why bother with .net when you have Thin Client?
By Albert D. Kallal
Monday, September 02, 2002
 http://www.members.shaw.ca/AlbertKallal/Articles/ThinClientsand.net.html

Albert D. Kallal
Edmonton, Alberta Canada
Kallal@ msn.com
http://www.members.shaw.ca/AlbertKallal
Albert D. Kallal Send private email
Sunday, May 01, 2005
 
 
I'm curious.  How scalable is an x-windows or citrix-type solution?  Each server is in effect running each user's program as well as maintaining some sort of virtual screen-display, right?  Does this scale very well beyond 50 or 100 users?  Is it easy to even get that far.

One of the great advantages of web servers is that they are stateless and can scale way, way up. Browser-based apps can scale.

WinForms (or Win32) clients that issue rpc's to a stateless internet server can also scale way up.  Potentially even more than an html-browser-based app since the requested data from server doesn't include all the html-formatting garbage and because having the client on the desktop lets the server offload lots of the processing that would otherwise be centralized on the server.

Isn't that a big difference?  Or am I wrong that x-windows and Citrix solutions have limited scalability in comparison to browser-based or rich-desktop-client-based apps.
Herbert Sitz Send private email
Sunday, May 01, 2005
 
 
Hey Albert,

Your article makes a good point, but I'm asking a more fundamental question: why is there even a difference between developing an app to be run locally vs. remotely? Why isn't the internet just another layer of abstraction, as it is with X? Why does my app have to even be aware of the user's physical location? Why do *I* (the developer) have to be aware of it?
John Foxx
Sunday, May 01, 2005
 
 
Because it's so bleeding slow
LC
Sunday, May 01, 2005
 
 
>I'm curious.  How scalable is an x-windows or citrix-type solution?  Each server is in effect running each user's program as well as maintaining some sort of virtual screen-display, right?  Does this scale very well beyond 50 or 100 users?  Is it easy to even get that far.

Well, there are certainly systems with 200-300 users out there. 

And, even 500 users is possible. (And, yes, a virtual display is maintained). I certainly prefer the design of UNIX x-windows, as the “output” of a program is sent to any other computer. Thus, with correct permissions, I can launch software on your computer..but the output (socket) sends all UI to my computer. Thus, unlike windows RDP, with x-windows you don’t have to reserve A “whole” desktop for someone to run the application.  It is on a application by application bases.

With RDP, you do have to work from a whole desktop. However, memory use is actually NOT as bad as you think. Remember, all windows code is re-entrant. If you launch two copies of the internet explorer…or 15 copies, there is only ONE copy of the code that runs in memory. (that is why you can easily run 15-20 browser windows….but try running 15-20 different programs at once..and see what happens to your computer).

And, that means if you launch word, or excel several times…each additional copy of word you launch is in fact using the SAME code base that was loaded into memory ONCE. (the code is re-entrant).

The same process occurs with Windows Terminal server. So, if you got 10 users all running Excel, there is in fact only ONE copy in memory.  This has the weird effect that often with more users, chances are that one user already loaded the application you need to run, and it is already in memory. So, often it seems faster! So, while the first user might wait for word to load into memory….after that it is a free lunch for each additional user (of course, each user will requite memory for their session variables used..but the code is already in memory).

So, 100+ users is quite easy.  Only about 10 megs of ram is going to be needed for each user here. To state that you don’t need as much hardware resources and a machine with as much juice as possible would be un-kind! So, you do need large amounts of hardware here. And, you have to be aware that for data entry type users that don't run a lot of software RDP (TS)is a great solution. For more advanced applications like graphics stuff, or informaton type workers, then often thin client can not cut the mustard here.

I know of companies still using old p-90 compurters..and they just rolled out office 2003 (no hardware upgrades, no memory upgrades…in fact NOTHING was done to the computers in the office, since now all support, and managing of the computers is central).

 And, the remote desktop can be run from a browser session now also.

Albert D. Kallal
Edmonton, Alberta Canada
Kallal@ msn.com
http://www.members.shaw.ca/AlbertKallal
Albert D. Kallal Send private email
Sunday, May 01, 2005
 
 
> The same process occurs with Windows Terminal server. So,
>if you got 10 users all running Excel, there is in fact only
>ONE copy in memory

If there is only a single OS process serving multiple users, how is security enforced?  What security credentials is that process running with?  How does excel handle messages going to the same queue from different user contexts?  There is only a single printing thread in WORD that will only process one print request at a time.  How would multiple users running a single process be able to print at the same time?

I just don't see how this could be done.  It's possible for the OS to share read only sections of executable files [CODE/CONSTANT DATA/RESOURCES], but I can't see multiple users sharing the same process space.  Is this what you mean?
cipher
Sunday, May 01, 2005
 
 
Below is some text from a Citrix whitepaper that tested scalability of Office 2003 apps on a Citrix server, recommending a max of 60 to 65 users on a Dual 1.4GHz Pentium server. 

Yes, I realize it would likely scale higher with apps less intensive than MS Office apps, but this doesn't sound that great to me.  I guess it's a decent solution for internal business use.  Maybe even for some proprietary apps over the internet.  But it seems kludgy to me, though I'd be hard pressed to show how it is essentially any more of a kludge than browser-based apps.   

------------------------
KEY FINDINGS:

CPU. The primary factor affecting scalability observed during the scalability analysis was CPU utilization. . . . 

Memory. Memory consumption was the secondary limiting factor after CPU utilization. Baseline tests indicated that the average memory consumption per user was approximately 34MB. . . .

User Limits. Maximum observed server load on the system was 81 for “Standard Word” users, and 57 for “Power Office” users. For the purposes of this test, the more conservative figures of 60 to 65 users reflect tests with minimal transaction errors and good application response times. . . .
---------------------------
http://www.citrix.com/site/resources/dynamic/partnerDocs/Office_Scalability_Analysis.pdf#search='citrix%20scalability'
Herbert Sitz Send private email
Sunday, May 01, 2005
 
 
"How would multiple users running a single process be able to print at the same time?"

Not only that, remember that the data you want to print exists only at the server, not at the client.  Your application shows you only the virtual screen that is running on the server.  I don't know how it works, but it seems to me that if you were not at the server location you'd have to first somehow download the file you're working on and have some application format and send it to a printer local to your client machine.  I assume this is automated by the Citrix clients, but again, it seems kludgy.
Herbert Sitz Send private email
Sunday, May 01, 2005
 
 
>: why is there even a difference between developing an app to be run locally vs. remotely?

Yes…that is my question also!  What a great and seemly simple question!!! I agree, not ONE thing should have to be done to run my software remote. I can’t agree more with your “why”. When I think of the current situation, it is kind of mess in a sense. 

The unix X-windows does kind of deliver this.  I guess the real answer is that MS windows has it roots in the desktop, and was never developed from the ground up to be used remotely.

Technologies are in fact moving towards the day when where you run the software will not matter. However, hooks, and things like inter-program communication are also needed. So, the industry is moving in this direction.

You see,  x-windows came out about 20 years ago. Back then, the concepts of inter program communication were not much on the minds of developers. The big deal back then was that program output could be sent to another computer. So, in a sense, it did not matter if the software was on your computer…or a some server somewhere else (gee,  as I type this…I am kind of shaking my head..and asking what the heck happened, and how did things go so wrong!!).

I will admit that today,  not only do we want to sent the output somewhere else, but also need a system where applications can communicate with each other. (soap, xml etc with the .net frame work does solve this problem).

The other big problem is that web came along, and while the network aspect of the internet is fabulous, the browser was not the best way to go IMHO.

So much of the efforts of the last 10 years have been building a rich desktop environment, but money is now pouring into technologies that allow software to run somewhere else, and we will get to that point where it don’t matter too much where you software actually runs.

Albert D. Kallal
Edmonton, Alberta Canada
Kallal@ msn.com
http://www.members.shaw.ca/AlbertKallal
Albert D. Kallal Send private email
Sunday, May 01, 2005
 
 
"You don't hear much about SSH + X for web apps, as an alternative to the kludgy mess we have now (HTML + cookies + Javascript + DHTML + Flash + God knows what else). I wonder why?"

On my website (which is a combination of a number of different applications: reviews, forums, as well as regular content), I have an average of 5,846 unique vistors per day on average (the max was 14,073 in a single day last month).  As mentioned in previous posts, the scalability of X or RDP is only a few hundred users.  I also used 78GB of bandwidth last month, I can only imagine but X/RDP would be MANY MANY times that.

This site runs off a single server that has specs that are slightly better than the desktop I'm using to compose this message.

I think that really answers the question.
Almost Anonymous Send private email
Sunday, May 01, 2005
 
 
>I can only imagine but X/RDP would be MANY MANY times that.

No, not so fast here. RDP is a highly specialist protocol that is essentially the windows drawing api across the web. HTML actually sends big text commands in ASCII to draw things on a screen! When you go back in time, the idea of using text type commands with all kinds of delimiters <start> </start> etc is really a huge waste here. With the RDP (remote desktop protocol), highly specially byte commands are sent down the wire. There is NO text interpatat5ion going on at the client end, and at the server side, byte, or much like p-code commands are sent. In other words, a highly compiled and tight set of commands are sent down the wire.  These byte/number type commands are FAR FAR more efficient then something like HTML. This is very much like using source code vs compiled tight byte code (your compiled code is usually MUCH MUCH smaller then the source code). A command to draw a box on a screen is NOT text based command like HTML, but binary numbers. Thus, the protocol is considerably more efficient then a browser and HTML.

The only area where things really fall down is that the windows interface is far richer then HTML, and often graphics and bit mapped images have to be transmitted. (but, often, code that draws a nice windows interface actually uses windows api drawing commands to draw things. So a nice filled box with a cool gradient is only a command to draw the box and fill it. Not the whole bit map. So, a cool drop down menu takes very little bandwith here.

So, in effect, you are correct that TS would take a LOT MORE bandwidth in your case…but that is not due to TS being less efficient then HTML, but due to the fact of what you are sending down the wire. But, for drawing boxes, placing text on the screen…RDP runs absolute circles around HTML.

Albert D.Kallal
Edmonton, Alberta Canada
Kallal@ msn.com
http://www.members.shaw.ca/AlbertKallal
Albert D. Kallal Send private email
Sunday, May 01, 2005
 
 
>If there is only a single OS process serving multiple users, how is security enforced?  What security credentials is that process running with? 

Security works exactly as it does now in windows. When you connect to a server (in this case…you also log on to the server).

Heck, try setting up your windows XP to allow multiple logons.

You can see in the main menu that both users are running programs. Here is a screen shot:

http://www.members.shaw.ca/AlbertKallal/ts/index.htm

Both of the users have applications running. And both have their own logon, and also their own permissions. This is standard windows XP here.

>How does excel handle messages going to the same queue from different user contexts?  There is only a single printing thread in WORD that will only process one print request at a time.  How would multiple users running

Try launching a 2nd copy of word on your pc, and see how it works! (it works very well).  This is no different then asking how can you have multiple copies of the browser running at the same time?  While ms-access when clicked on actually launches another copy, both Excel, and Word have been designed to use the existing copy. This is so that each document a user clicks on does NOT launch antoher copy of word. This is to prevent users from hanging themselves with a rope! However, write a two line tiny windows batch script to launch that 2nd copy of word. Try the follwing:

Paste the following code into a standard notepad (text) document. Lets call it word2.txt

set ap = createobject("word.application")
ap.visible = true

Type the above two lines into that text document. (just put the above on your desktop). Ok, now, rename the extension from .txt to vbs. (you don’t hide your extensions do you? (this will not work if you have extensions hidden)). Ok, note how when you change the above .txt to a .vbs, it changes to a cool “scribe” type icon

Now, launch word as you usually do (from the start menu…or click on a word doc). To launch a 2nd copy (or 3rd, or 4th etc…just click on the new script you just made).

You can now run as many copies of word as you wish. If you bring up the task manager, you will see two copes of word running.

Remember, windows is multi-user able.  In this case, you will have two complete separate copies of word running. Each copy will have its own print que etc. 

Really, not a lot of difference between one user running many programs at once, or several users running several programs at once. Or, several users running one program at once.

I mean, how does any multi-user computer work? For sure, the fact that windows has re-entrant code is quite nice. Re-entrant code means that code cannot be self modifying, and does not contain any bad coding practicies! Each process of course gets its own registers space, processor stack etc, and is swapped in and out for each task.

As I mentioned, the process by which you have more then one copy of software running on your desktop is not a lot different then how a multi-user system works.

Computers have been multi-user for some time now. This is nothing new in our industry.
 
In fact, there was a version of the windows XP beta that allowed un-limited logongs to windows xp. This was going to be a new feature of windows xp, or was for testing. It was dropped towards the end of the beta testing.

Albert D. Kallal
Edmonton, Alberta Canada
Kallal@ msn.com
http://www.members.shaw.ca/AlbertKallal.
Albert D. Kallal Send private email
Sunday, May 01, 2005
 
 
"HTML actually sends big text commands in ASCII to draw things on a screen!"

No, not so fast here.  Those big text commands are high level commands that describe overall layout.  HTML isn't filled with commands like:

<box x="5" y="7" height="10" width=50" /><drawText x="10" y="33">Some text here</drawText>

HTML is far more high-level compared to RDF.  In addition, pretty much all the HTML that is sent over the internet is compressed anyway.  I doubt that it's much larger than binary RDP code.

"The only area where things really fall down is that the windows interface is far richer then HTML, and often graphics and bit mapped images have to be transmitted."

And in this case, the entire HTML environment is much more efficient.  All the images, CSS!, and client side code I use on my site are downloaded once and cached on your machine.  No matter how much you navigate around my app, you never have to download it again.  That's a huge savings and something that RDP simply cannot duplicate.

I worked on a site with a huge number of long forms; I have client-side validation and lots of other client-side interaction.  Users can literally spend an hour on a single page and that entire time they aren't connected to the server. With X or RDP you waste server resources just sitting there doing nothing.  How much time are you really actively using an application (sending/receiving data) in day?  How much time did I use composing this message?  How much time did you just waste reading it?  That's a massive waste that also needs to be factored in.

X/RDP has it's uses (I use it almost every day) but clearly it's no replacement for HTML and all the related technologies (CSS, GIF, JPEG, Javascript, SVG, etc).
Almost Anonymous Send private email
Monday, May 02, 2005
 
 
How many flash adds can a single terminal services box be serving?
Just me (Sir to you) Send private email
Monday, May 02, 2005
 
 
Oh, the horrors you hear when people who haven't tried the accepted way to do something, and don't bother to find out, still want to redesign it because they think something else is a priori better.

When all you have is a hammer, everything seems like nails...
ping?
Monday, May 02, 2005
 
 
First, and foremost we want to distinguish between server side resources and bandwidth to transmit a screen.

And, of course we need to distinguish what I am talking about when I say RDP is more efficient then HTML. I am ONLY talking about the amount of data to draw a screen.

Without question, the web based solutions are FAR FAR FAR more efficient then Citirx (or TS) in terms of memory, and processing used on the server side.  No debate there. And, I would say the same when running a application, that TOTAL bandwidth used by web based technology is again MUCH MUCH less then RDP.  Given these issues are now clear. I can make the following points:

>With X or RDP you waste server resources just sitting there doing nothing.  How much time are you really actively using an application (sending/receiving data) in day?  How much time did I use composing this message?

That is also a fair point.  There is a MUCH greater use of bandwidth to “run” the application with TS. My only point here was that TS is very efficient in transmitting a screen to the client, and more so then is a web based solution. The problem is that each entails a complete different model of functions.


>>and often graphics and bit mapped images have to be transmitted."

>And in this case, the entire HTML environment is much more efficient.

Actually, TS and citrix also caches bit maps.  Thus, once run, then the application can cache the screen graphics (and they do a better job then web browsers).

Further as mentioned TS has a api to draw things like drop down menus etc. So, those windows widgets (controls) are not transmitted, but only commands to manipulate those windows controls.  So, we got two issues here:

TS is going to draw and display a rich windows application WITH LESS bandwidth then HTML.

However, you are correct to point out at the end of the day, a TS application will consume CONSIDERABLY more bandwidth then a HTML based solution.

My only point here is that HTML is not as efficient as TS in transmitting and drawing a screen.

I suspect for simple screens that HTML is built around, then it might be close to TS in terms of bandwidth needed (to draw the screen here).  However, RDP still wins in most tests I seen. Using text commands VS a tight windows API is a lot better then text commands.

To quote a bench mark on this issue:

<quote>
For this benchmark, the remote display encodings used by ICAWin and VNCLin were more efficient in delivering the display of the web page to the client than native HTML. Since the remote display mechanisms only display what is actually viewed on the client, they do not need to display portions of the web page that are not displayed whereas the PC fat clients need to completely download all of the data associated with the web page
</quote>

PC fat clients in this case are web browsers.

In other words, unless those web pages are sized exactly to the size of the screen, MORE THEN ONE screen full of data is often set for a web page to be displayed.

There is also the issue of HTTP vs that of TCP. HTTP runs on top of TCP. The browser can often submit multiple requests and this can consume a LOT of bandwidth. (what is the apache max setting…100?). I must point out that if you download something in ½ the time (twice as fast)..then you don’t actually use more real bandwidth, but those browsers can really gobble up bandwidth due to the way that HTTP gets/put and TCP function.

The RDP is much more careful in this regards.

In addition, single characters, and clicks can be processed by thin client. With HTML, the get/put sequence as a general rule has to send the whole (or at least larger) mess back to the server.

However, as you point out, after the screen is drawn, the web based HTML solution will NOW consume MUCH less bandwidth, and I certainly agree with this (since the Thin client will have continuous communication occurring).

There is quite of few issues to consider here. I still maintain that RDP is far more efficient then HTML.

However, the applications that are HTML based will consume considerably less bandwidth then RDP based applications.

So, I don't in any want want to suggest that RDP applications will compete with HTML, but RDP does as a rule seem to consume less bandwith to draw a screen, and is not as bad as one might think....

Albert D. Kallal
Edmonton, Alberta Canada
Kallal@ msn.com
http://www.members.shaw.ca/AlbertKallal
Albert D. Kallal Send private email
Monday, May 02, 2005
 
 
"And, of course we need to distinguish what I am talking about when I say RDP is more efficient then HTML. I am ONLY talking about the amount of data to draw a screen."

And you specifically mean the amount of data to draw a *single* screen.  I never claimed that RDP was an inefficient protocol in and of itself.  I'm sure (especially from using it) that it's an extremely efficient protocol.  I remember using it over a dual-ISDN line and not being able to tell the difference from using the PC locally.

However, you cannot simply compare RDP and HTML based on the amount of data to draw a single screen.  As you said, HTML over the long haul is going to be more efficient (send less bytes) than RDF.  And even the perception of performance can be better with HTML.  Clearly what the user thinks is most important.

I'm also not saying that HTML is inefficient in and of itself.  Sure it's text-based and all the arguments that are currently going on with XML vs. binary formats apply equally to HTML.  There are good points on either side of that debate.  But HTML is not simply a text-based version of RDP -- it's something entirely different.

"My only point here was that TS is very efficient in transmitting a screen to the client, and more so then is a web based solution."

A web based solution does not transmit a "screen" so it's not a fair comparison.  When viewing this forum page, several screens (scrolled) is transmitted at once.  This might make that first screenfull seem slower but scrolling the page is super efficient compared to RDP.  You can think of it as "preloading".

TS doesn't know what's coming before it's needed, nothing can be preloaded.  You can preload graphics (this is a pretty standard feature of all mouse-over scripts, for example).  If you're browsing Google in Firefox it will even preload the first search result.  This makes HTML less efficient in terms of bandwidth but is great from the user perspective.

"Further as mentioned TS has a api to draw things like drop down menus etc. So, those windows widgets (controls) are not transmitted, but only commands to manipulate those windows controls."

This is not an advantage over HTML since HTML also uses an API to draw things like drop down menus, textboxes, buttons, etc.  Also, one can think of CSS as creating new API's for complex elements.  My website, for example, has a drop-down menus described in the HTML as simple <ul> and <li> tags yet the result on screen is a complex widget.

"In other words, unless those web pages are sized exactly to the size of the screen, MORE THEN ONE screen full of data is often set for a web page to be displayed."

As mentioned above, I consider this an advantage from the user perspective.  As the designer I choose how many screens need to be transmitted based on intent.  For some screens, I just send a single screen because that's all the user needs.  For other screens, I might send 30 scrollable screens of data because I know the user wants to see that much.  It's less efficient if the user decides not to read all 30 screens but it's a much better user experience if he does.

"HTTP runs on top of TCP."

RDP runs over TCP.

"I must point out that if you download something in ½ the time (twice as fast)..then you don’t actually use more real bandwidth, but those browsers can really gobble up bandwidth due to the way that HTTP gets/put and TCP function."

You'll have to explain this one further, I don't get it.

"In addition, single characters, and clicks can be processed by thin client. With HTML, the get/put sequence as a general rule has to send the whole (or at least larger) mess back to the server."

At last, you finally hit on a real disadvantage of HTML.  The server round trip is pretty expensive in terms of sending lots of data and completely regenerating the resulting screen.  This is also a terrible user experience.

I try and do a lot to mitigate this.  I have client-side input validation for all the forms.  I'm also now working on adding AJAX elements to allow uses to manipulate the page without refreshing.  That should make the HTML page much more efficient but this all *a lot* of extra work.

RDP doesn't have the server round trip but it sends an IP packet for every mouse move, mouse click, and keypress.  In some cases this is good from a user perspective because the app responds instantly.  But it can also be bad; I frequently have "stutters" when doing lots of typing over RDP -- sometimes keypresses can take a few seconds to register.

"So, I don't in any want want to suggest that RDP applications will compete with HTML, but RDP does as a rule seem to consume less bandwith to draw a screen, and is not as bad as one might think...."

For a single screen I agree, but that's an artificial metric.
Almost Anonymous Send private email
Monday, May 02, 2005
 
 
>>HTTP runs on top of TCP."

>RDP runs over TCP.

Ah, ok..I did not explain that one! HTTP runs on top of TCP. It does not care, or have any control over how much bandwidth, or even how many requests are used. RDP (and better yet Citrix ICA) “is” a protocol in which the max pipes (sockets, channels..or whatever you want to call them) is controllable. These protocols can thus regulate, and utilize different settings (packet size, timeouts…a very large number of things exist in the TCP protocol). Citrix lets you control much of the settings used. It is possible that larger control(s) exists on the HTTP (server side) settings, but I don’t think near the same LEVEL as the RDP, or ICA protocols. And, we do have to distinguish between protocols, and the ‘server side’ settings for the particular software. If the web serer (HTTP) has more controls in this regards then I know, then perahps my point is not valid. However, my point was that ones hands are “usually” tied more with HTTP then these custom protocals.

A large web page can easily fire out 200 requests and 200 sockets are opened in this case. Thus, the next issue comes up:

>>I must point out that if you download something in ½ the time (twice as fast)..then you don’t actually use more real bandwidth, but those browsers can really gobble up bandwidth due to the way that HTTP gets/put and TCP function."

>>You'll have to explain this one further, I don't get it.

Sure, I was just pointing out that a browser can send more then one get..and thus you get a large bandwidth spike. However, I would be making a dishonest argument if I did not also point out that if you have 4 or 6 “gets” running in  parallel, while you get a huge bandwidth spike, the spike lasts (in some cases) will last 4 or 6 times less (assuming we have NOT yet reached max bandwidth here)
 
So, “GETS” can increase the bandwidth spike and that can be a bad thing as everyone now in the office experiences a slowdown in their internet speed. However, I also have to point out that sometime this increased spike in bandwidth also results in LESS TIME for the page to be sent to the browser. The end result is

      More bandwidth over less time = less bandwidth over more time

Often, you have 5, or 10 machines working in a office with a shared (and limited) internet bandwidth. You don’t want one pc grabbing issuing a zillion GETS and using ALL of the bandwidth while all other users machines freeze up. (but, as above shows…you are not using more bandwidth if you load the data in faster (in less time)…or slower over more time. So, I was just trying to be fair here, and NOT point out only ONE side of this issue (since, if I did not point out both sides..then you would be forced to respond! As you can see my crappy poor explain the first time around did not save us any time since I had to explain both issues here again due to my crappy explain!!!!).

The issue is how all the users in the office are effected when a page loads and the bandwidth can’t be carefully controlled PER user. (citrix even lets you control bandwidth for the clip board, as one accidental paste from the client pc to the citrix session can swap a weak network). (the clip board is one of 4 channels (sockets) that citrix uses).

I do apologize  for being so wordy here…but I learned some great things here, and have enjoyed this thread very much….

Albert D.Kallal
Edmonton, Alberta Canada
Kallal@ msn.com
http://www.members.shaw.ca/AlbertKallal
Albert D. Kallal Send private email
Tuesday, May 03, 2005
 
 
> Security works exactly as it does now in windows. When
> you connect to a server (in this case…you also log on to
> the server).

Umm No.  You said that each user will share the same OS process for WORD.  If there is only a single OS process running on the server for all users running WORD, then what security context does that process have?  Note that I'm talking about an OS process context.

> Really, not a lot of difference between one user running
> many programs at once, or several users running several
> programs at once. Or, several users running one program at
> once.

What??  There's an enormous difference between a single user running multiple apps, and multiple users running a single app each.  For starters, a single user will only be interacting with a single application/process at a given time.  Multiple users will [potentially] be collectively interacting with multiple applications at a given time.

> Heck, try setting up your windows XP to allow multiple logons.

I did and I confirmed my suspicions.  There are two separate OS processes [one for each user session].  I confirmed this with process explorer from sysinternals and by the fact that they have different pid values.  Launching WORD twice under the same user session will only create a single process.  Win32 programmers have been doing this for ages [FindWindow()].  Launching EXCEL under the same user session creates two OS processes incidentally.

> I mean, how does any multi-user computer work? For sure, the fact that windows has
> re-entrant code is quite nice. Re-entrant code means that code cannot be self modifying,
> and does not contain any bad coding practicies! Each process of course gets its own
> registers space, processor stack etc, and is swapped in and out for each task.

Actually, the fact that a different process space will be created for each connected user using the application means that they will be working with a separate HEAP and stack [or stacks if multiple threads are active within the process], so the code being re-entrant is not relevant.
 
My original thoughts regarding terminal services are correct.  Windows has something called a desktop context.  It would seem that each terminal services session [connected user] have their own separate desktop context.  Each user interacting with an application will get their own copy of the application via a separate OS process.  If you have 100 users using MS Word then there will be 100 OS processes for MS Word.  Each with its own HEAP and stack[s] and message queues.  However, the NT kernel will most likely share read-only code pages among those processes.  It may even have a copy-on-write algorithm used to share writable pages that haven’t written to yet.  But there are separate processes for each user instance of the application.  Given that,  it still may perform fairly well.

I don’t know how true this is, but a few of my clients [Canadian Fed Gov’t] that use terminal services have told me that MS recommends rebooting the servers on a nightly basis.  Is there any truth to that?
cipher
Thursday, May 05, 2005
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz