Metaframe 1.8 and reflection 8.04

[Jaapvs]

We're using Citrix metaframe 1.8 on W2000 servers and installed reflection 8.04 (for telnet sessions) on all Applicationservers to access the UNIX-machines. Now we get problems especially when users start 2 reflection sessions (using r2win.exe)it generates (only sometimes) very high CPU-activity causing other citrixsessions to slow down considerably. When we confronted WRQ (the manufacturers of reflection) with this problem tey couldn't come up with an answer (yet). It looks to me like a protocol issue.
Did anyone have similar experiences or a solution to this problem?

 

[CitrixEngineer]

From the information you've given, I don't see how it could be a protocol issue - could you clarify this?

Are you saying that if a single user has >1 session this occurs, or if >1 user has a session?

The simplest test here would be to try running the application via a Terminal Server client, and see whether the high CPU usage issue remains.

Hope this helps

 

[Jaapvs]

I think it might be a protocol issue because of three things: 1 CPU usage gets very high without addressing a lot of memory (I think that it might be a indication; if you can prove me wrong please do so).
2. I've heard of problems with reflection's own tcp/ip protocol (reflection 7 I think it was). They say that they fixed it but ...
3. The only thing reflection does here is make some keyboard mappings (telnet / terminal emulation) which should generate only a very small amount of cpu-usage.
The problems occur when one user starts >1 session.
By the way if I start 2 sessions without the keyboard mappings the problem doesn't seem to occur.
In addition to this; already a WRQ-person has confirmed that the installation was done correctly, but they still didn't have an answer to solve the problem.

 

[CitrixEngineer]

I haven't used reflection X, but it looks a lot like some other Terminal Emulators I have used. I had a quick look to see what I could find on it, this seemed to be the most informative page;

http://support.wrq.com/techdocs/1507.html

I note that the company support version 8 with Windows NT4 Terminal Server, Windows 2000 server and Citrix MetaFrame - can they be pushed for suggestions? I assume your company paid them a lot of money for this product!

QUOTE/
The following issues are resolved in Reflection X 8.0.2:

Reflection X runs correctly on Citrix, Metaframe, and Windows Terminal Server (WTS).

Reflection X now supports Windows 2000/TSE.
/QUOTE

If this is the case, I would expect WRQ to sort it out!


There are some known issues with non-USB key-mappings that have been fixed in 8.06 - have you tried this upgrade?


Further thoughts (Brain Dump);

Since ICA does its own keyboard magic, it could be possible that having more than one session to an app that does its own mapping could disproportionately increase processor load - but that would be tricky to track down unless you had suitable debug tools.

If anything is happening at "DOS" level, then maybe the DOSKBD utility or similar could be used.

If the problem goes away when using a terminal server client, then there is clearly an issue with ICA. Make sure compression is turned off in the clients - this forces more processing on the servers CPU.

ICA depends on the IP protocol - which should be handled by the Operating systems, not the applications. I may be mistaken, but I thought that TCP/IP was a defined suite of protocols which tell the machines how to communicate on the network. ICA delivers to the presentation layer, and Reflection X does its stuff at the application layer - effectively insulated from the protocol.

I had best results with MetaScybe Connect OSI, for plain Terminal Emulation - although it took me a while to sort out the keyboard. For full X-Window support, however, I use MFU! ;-)


I hope at least some of this helps

 

[Jaapvs]

WRQ did provide a solution now. Apparently there was a problem with some of the (reflection basic) scripts. It worked fine with Novell but reflection basic, not being my favoutite language (And I guess it never will be), I won't (can't) bore you with details about the solution.
So it was no protocol issue after all or a problem with the keyboard mappings.
Thanks anyway for the suggestions and further thoughts, they may very well be helpfull in the future.