HOB Techtalk

Integration of the HOB Windows Terminal Server clients HOBLink JWT and the 3270 client HOBLink J-Term in Eclipse

Originally, Eclipse was used in the development environment, i.e., as an application program for the development of software for the programming language Java. As the successor to IBM Visual Age for Java 4.0, the source code for Eclipse was released by IBM on 7 November 2001. On 2 February 2004, the Eclipse consortium, lead by IBM, decided to found the legally independent Eclipse Foundation, which since then has been responsible for the development of Eclipse. Eclipse is Open Source software and can be downloaded free of charge.

Due to its expansibility, Eclipse is also used for many other development tasks. There are many extensions from both open source and commercial providers.
Up to and including Version 2.1, Eclipse was designed as an IDE. Since Version 3.0, Eclipse is only the core that loads the individual plug-ins, which themselves supply the actual functionality. Eclipse and the plug-ins are completely implemented in Java. SWT is used to create the graphical user interface. For the display of the GUI components, SWT, similarly to AWT, uses the native GUI components of the corresponding operating system. The plug-ins can be installed either by downloading them directly from an update server or simply by unpacking them.

Increasingly more enterprises are deploying Java products and more and more often using Eclipse as the framework on the workstation computer due to the advantages thereof. A very popular and widely used application for deployment with Eclipse is Lotus Notes from IBM. With the Lotus Expeditor, the GUIs for Lotus Notes can be created and integrated on the basis of Eclipse (RCP, Rich Client Platform). Eclipse is itself written in Java and can therefore be used on any platform and on any client operating system.

The use of Eclipse as the framework on the workstation computers in an enterprise brings with it the following advantages:

• A uniform base for the use of any application program as a Java plug-in in heterogeneous client environments


• Very open and flexible design of the client’s GUI


• All application programs used as plug-ins can be easily given a uniform display format


• Standardized software interfaces allow the deployed plug-ins to be linked with each other, e.g., for data exchange, etc.
   
• The integration of the individual application programs into the Eclipse framework simplifies the rollout to the work areas and, as a result, also the administrative work.

A disadvantage of this design is the fact that desired applications are not always available as Eclipse plug-ins. Early on, HOB recognized the need of enterprises for applications as Eclipse plug-ins and thus offers two important client applications as plug-ins for Eclipse:

HOBLink J-Term, the first and most performant 3270 emulations in Java
HOBLink JWT, the RDP client for Microsoft Terminal Server in Java

Both products are in use at well-known corporations. HOB has placed great importance on the providing the Eclipse plug-in versions with the same scope of functions as the native versions.
The “look and feel” and the performance range of the native versions and the Eclipse plug-in versions from HOB are absolutely identical. A user who has previously worked with a native version and switches to the Eclipse plug-in version can work with this version just as before.

For further information, please see:

www.hobsoft.com

25 February 2010

Klaus Weinbrenner

 

 

As written in the previous entry, SSL VPN solutions have not entirely replaced IPSec VPN solutions. But they sure are trying hard to.

Where IPSec VPNs would open the entire network at once, SSL VPNs have slowly but surely undertaken the task of moduling the possibilities. Should a user only have access to an internal Web server, the administrator can limit him to just that. Should he only have access to a specific Terminal Server, or his office PC, he can also limit him to just that. But it also means that the SSL VPN must have the correct tools to make the connection to these allowed targets.

Imagine a restricted building where a card can either open all doors or be entirely rejected, that's your IPSec gateway. Imagine now an improved system where you can code each card to open certain doors, great! But what good is this if there is no elevator, or hallway to go the doors you have clearance to?

 

Where the IPSec solutions mostly rely on the software installed on the client computer for access (use your own feet, a climbing rope, or a flying jetpack if you can – clearance is there, you provide the connection), SSL VPN appliances want to provide this software itself. The goal is to limit the requirement on the client PC to what is probably already installed on it (namely a Web browser and tools like Java or ActiveX – we don't assume you have anything else than 2 legs, feet and well... some shoes). This makes the administrators' work easier (working on a single, familiar, accessible point) and the users' interface more independent of their PC. So these appliances come with plenty of tools which cover most of the needs of a regular user. But then some rooms are not used so often, or some client PC are even more different than your usual unusual PC, and these cases are not covered by the « out-of-the-box » appliance (« Sorry, you're too tall for this safety elevator and there's no stair »!). Then all of a sudden the advantages of the solution become a difficulty: The administrator is limited by the appliance's possibilities, and the user can't do anything on his homebrewed client system to change anything. The software on the appliance has to evolve.

 

It is this way that we are receiving more and more interest from SSL VPN customers in our Java RDP client: HOBLink JWT.

Most SSL VPN appliances come with a usual RDP client, Microsoft, Citrix, and an open source Java client. This basically covers the needs of Microsoft OS clients, and if ever you are connecting from a Mac, or a Linux, well this open source client should cover your basic needs until you can find better.

More and more customers' answer to this is “that's not good enough”. Surely it must be possible to connect from my Mac to my office PC without having to give up on my keyboard layout, printer, dual-screen, or any normal option you need to work correctly. What about 64-bit OS? they are not a rarity anymore and should be covered (The average human population is getting bigger with time and there is no doubt that the computer world is changing much faster!).

HOBLink JWT is our answer. A Java RDP client that can be hosted on a Web server behind your SSL VPN appliance (ie no installation either on the client nor on the Terminal Server / Office PC), with full functionality and running independently of the platform.

 

We followed the demand and started with the world leader of SSL VPNs: Juniper. More and more customers hosted HOBLink JWT on a Web server behind the VPN, and it would act as it normally does with a link (bookmark) on the users' interface. But we wanted to push it a bit further, using the possibility in the Juniper VPN to host Java applets directly on the appliance. This does not only save on a Web server, but also improves the speed of the connection. Working together with Juniper, this was made possible for JWT 3.2, and now further improved for JWT 3.3 on the Juniper releases 6.4R1+.

Soon HOBLink JWT will be integrated directly in the appliance, to ease the process for the end customers.

SSL VPNs are going one step further in replacing IPSec VPN solutions, and your elevators are about to become much more flexible – no less secure.

 

02/08/2010

Laurent « Chipper » Vaucheret

Support Engineer, HOB Inc.

 

VPN’s (Virtual Private Networks) used to be created with the IPSec protocol (Internet Protocol Security). Newer solutions are based on SSL (Secure Sockets Layer). SSL-based solutions can be used in the same way as IPSec solutions; with SSL, however, there are also solutions that are principally different than IPSec solutions.

 In this article the differences between SSL and IPSec, and the advantages of SSL over IPSec, will be discussed.  This article deals exclusively with solutions for remote access from laptops or PCs. In gateway-to-gateway connections, which for instance are used for connections to branch offices, using SSL doesn’t make sense, so IPSec continues to be used in such scenarios. Also, devices such as the Apple iPhone or other cell phones with Microsoft Windows mobile as a standard have an embedded IPSec client. The advantages of SSL don’t apply here; therefore it doesn’t make sense in this case to replace IPSec with SSL. 

This article is organized into the following sections:

1. Where SSL can be used, but IPSec doesn’t work
2. System Architectures with IPSec or SSL
3. Compression with IPSec or SSL
4. Streaming with IPSec or SSL

 

1.       Where SSL can be used, but IPSec doesn’t work

Only Access over TCP Port 80 and 443 is possible

In the Internet environment such as in companies, hotels, or Wi-Fi Hotspots firewalls are used regularly as a form of protection from the public Internet. Since access to the protected areas should be possible, predominantly for the web-browser users, access over the HTTP TCP port  80 and the HTTPS TCP port  443 is allowed.  If there is nothing else configured in the firewall, IPSec definitely cannot be used.

  

Proxies within Company Networks for Access to the Public Internet

Proxies are used in many companies and organizations to regulate access to the public Internet. The protocol Socks 4/5 and HTTP are then utilized. Conventional browsers support access through such proxies. Microsoft ISA Server or Squid (Open-Source) are examples of proxies that are used. It could be required within the proxies that a user or a device must be authenticated before access to the public Internet is allowed. Different options can be used for the authentication: Username/Password, NTLM (NT LAN Manager) or Kerberos. It is possible within such proxies to check the incoming websites (HTTP/HTML) for viruses. With the appropriate constructive characteristics it is also possible to receive arbitrary data through the virus checker. Viruses are not received from the Web-Browser, but from the SSL Clients instead. Such proxies generally cannot be used with IPSec, only with TCP or SSL is access possible.

 

SSL over the HTTP TCP Port 80

There are installations, commonly found in hotels, where only port  80 is open and not the HTTPS/SSL-port  443. It is, in principle, possible to pass SSL data through port  80 so that access with the web browser (over SSL clients) is possible.

 

Costs for Hotel Internet Access

It has been reported that in many hotels there are different price models for Internet access. There is complimentary or low cost access over the TCP port  80 / 443 (where SSL can be used), but if one wants to use IPSec, then another, more expensive, price model must be chosen.

 

Low Cost Network Components

When a user is at home and wants to set up a VPN connection on the central network, then as a rule a standard DSL connection should be used. A DSL router is then used and it typically does the NAT (Network Address Translation). It has been reported that such DSL routers often cannot use IPSec, often not even with NAT-Traversal. 

                                                                                                                                     

2.        System Architectures with IPSec or SSL 

System Architecture with IPSec

IPSec solutions are usually set up so that a driver is installed on the client.  This driver installation creates a so-called virtual adapter in the system. Typically, the IP address used for communication with applications on the central servers comes from the central IT administration. The driver in the system intercepts all (or the relevant) IP packets, encodes them and then sends them over the IPSec tunnel to the server. Packets from the server travel the opposite path. There are also IPSec solutions with compression. 

Driver Problems

Modern operating systems are designed so that a faulty program doesn’t cause the operating system to crash nor disturb nor damage other programs. This is attained by allowing only the operating system to carry out critical actions such as input/output or memory management. If programs need such actions, they jump over the APIs (Application Programming Interface) in the operating system, the operating system checks whether the action can be carried out faultlessly and then the operating system carries out the critical actions for the application. 

Now, however, an operating system can’t always do everything alone; therefore drivers are used to extend the operating system. Drivers, in principle, are allowed to perform all actions, even the critical and dangerous ones. This is necessary because, otherwise, the applications would only be able to do what the standard operating system is designed to do. 

Several problems arise from these circumstances. One being, faulty drivers can cause the entire operating system to crash; with Windows one speaks of a “blue screen” event. Often data is lost by a system crash and it causes a big disturbance for the user, because he is not able to work for quite a long time (at least for as long as it takes for the system to reboot). 

There are specific interfaces in the operating system for drivers. Operating systems are constantly being further developed, so that these interfaces must always be changed. That mainly means that for every operating system version a specific driver is needed, which doesn’t work anymore with a newer version of the operating system. With normal applications this problem doesn’t exist because the OS manufacturers see to it while developing new versions that the interfaces to these applications (APIs) are maintained at a consistent level.     

Qualified developers are needed for the development of drivers and these are hard to find.  In comparison to normal applications, drivers are more difficult and more expensive to develop, debug and to test. 

In conclusion, it is to be said that the prevailing number of operating system crashes (“blue screen”) are not just errors from the operating system, but instead from the driver.

Microsoft, in Windows XP, introduced the function Windows Error Reporting (WER). This enables Online Crash Analysis (OCA) to be done. When Windows crashes with a blue screen event, than a small core-dump is generated and, after the user is prompted and agrees, this is sent to Microsoft. Microsoft was at the time quite amazed at the many core dumps they then received, the large amount of which was unexpected. As the received core dumps were analyzed, Microsoft discovered that faulty drivers were responsible for 85% of the errors, the small percentage remaining were actual Windows kernel problems. If there were fewer drivers in the system, then there would be correspondingly less annoyances and problems.

Full Network Access over SSL

With some SSL solutions there is also full network access over SSL, analogous to solutions with IPSec. In standard solutions a driver is installed on the client’s operating system, analogous to IPSec. HOB RD VPN PPP Tunnel, a new technique that is patent registered, has full network access without a driver, without administrator rights and completely without an installation on the client. The PPP Tunnel solution within HOB RD VPN is browser-based. 

Because with this solution everything is installed on the central server and nothing on the client, software updates are much easier to implement and constitute considerable cost savings. 

Access from the Client’s Web Browser over an SSL VPN to the Central Web Server   

One of the first and basic functions of SSL VPNs was to make access only via the client’s web browser. When a user wants access, he authenticates himself first on the SSL gateway and then he is granted access to all web servers in the central network. This access can be restricted if necessary by the configuration of the SSL VPNs; the user can then only access predetermined web servers. The communication between the client (web browser) and the VPN gateway is SSL encoded (HTTPS). For communication between the VPN gateway and the internal web servers, normal HTTP is used or, when needed, SSL can also be used. One speaks then of client-side SSL. 

This function sounds relatively simple; however it is expensive because all links in the web pages of the VPN gateway must be converted. This is principally possible for:

• HTML
• CSS
• Javascript, jscript
• Ajax 

However, there are restrictions and some general problems with websites with the following content:

• ActiveX
• Flash
• Silverlight
• Java

 

In addition, files can be exchanged in both directions with the central office over the browser. Not all SSL VPNs command these costly procedures for the conversion of web pages or for the exchange of files. With HOB RD VPN this function is called Web Server Gate. The exchange of files is called Web File Access.  

On the one hand, only web applications are predominantly developed or used in many companies, on the other hand only the normal web browser is needed on the client. For this reason, this form of access over SSL VPNs is often used. With IPSec VPNs there are no comparable functions. 

Redirection from the TCP Data Stream to the localhost

One of the basic functions of SSL-VPNs is the following: on the client a small proxy is started which was previously downloaded as a Java applet or an ActiveX  control from the SSL-VPN. Now the user can start on the client the desired applications. These then connect over the localhost to the local proxy and then to the corresponding server. To do this, of course, the application has to be configured differently.
The local proxy encrypts the data with SSL and sends it to the VPN gateway. The VPN gateway unpacks the data and sends it to the desired target or server. At HOB this function is called the Universal Client, elsewhere one speaks of port-forwarding. This function has certain limitations and only works when the client application establishes a TCP connection to the server; the other way around, a TCP connection can be made when the server wants to establish one to the client. UDP also cannot be used.
There are also problems when in the TCP data IP addresses are transmitted, as happens, for example, with FTP or RDP. Also in SIP and RTP IP addresses are transmitted in the data packets, but here the communications go over UDP and redirection over the localhost is, in principal, not possible.
When working with a local proxy, the Session Directory cannot be used with RDP for the Windows Terminal Server, because the RDP data stream is being redirected over the local proxy.
With HOB RD VPN, SSL is done directly in the RDP Java Remote Desktop Client HOBLink JWT and in the WebSecureProxy, so that the Session Directory function is also supported here, as opposed to solutions using local proxies and redirection over a localhost.
In many cases, the function with local proxies and redirection over a localhost is sufficient, yet it does not provide complete network access. However, in many cases complete network access is not at all desired.

3.        Compression with IPSec or SSL

In many IPSec solutions compression is incorporated, but after different methods, most of them deflate. 

With IPSec the packets are individually compressed, if a dictionary is used, it must be reset with each packet. This happens because IPSec is a connectionless protocol. This means packets can get lost, packets can arrive out of order, or they can arrive at the recipient with the wrong Checksum and then be rejected. Packets are also rejected from routes in the transmission network if the network is overloaded; this is a normal occurrence and is accordingly taken into consideration by all IP stacks. 

IPSec does not notice if a packet does not arrive at the recipient, these problems are handled at a higher layer, e.g., in the TCP stack. Due to the fact that with IPSec the dictionary is reset with every packet, the compression is less effective. Packets are mostly small with IPSec, MTU = Maximum Transmission Unit or MRU = Maximum Receive Unit is for example, with PPP RFC 1661 1,500 Bytes. With such small packets good compression is not possible. In the meantime, there are Gigabit Ethernet jumbo packets, up to 16,000 bytes, with these, better compression is possible, but, with WAN such large packets currently cannot be exchanged.

Compression with SSL

 SSL is connection-oriented and thus efficient compression can be used. Web browsers have a good command of compression methods such as zLib. The data is given in the HTTP header. The web browser doesn’t send compressed data itself; actually the packets from the web browser to the web server are typically quite small. But the web server (or an SSL gateway with the function Web Server Gate) can compress the response with zLib and thereby the corresponding web pages are loaded faster. 

Compression with zLib is built into HOB RD VPN Web Server Gate.  Web pages can be compressed even if the original web server sends the data uncompressed. 

With SSL the shared cipher suite is negotiated through a suitable method, which means deciding which encoding algorithms are used. 

The company Netscape originally invented SSL and had intended that while negotiating the cipher suite, a compression algorithm could also be negotiated. For this reason, HOB built this functionality into the corresponding SSL suite so that compression could also be used. This works, however, only when HOB SSL Suite is used on the client as well as on the VPN gateway. There are no other known companies, aside from HOB, that do compression on the SSL level. 

If with HOB RD VPN the PPP Tunnel with compression is deployed, Windows Explorer data, for example, is exchanged, and an effective compression takes place. In practice it was observed that the data stream was compressed sometimes down to 20%. The data exchange then goes much faster, just as with a virtually five times faster line. 

4.        Streaming with IPSec or SSL   

Applications like video or audio use streaming, i.e., a continuous data stream is sent. A special case of streaming is real time, such as VoIP (Voice over IP). In order to understand the suitability of IPSec or SSL for streaming, we must first look at the basics. 

Transmission Error

If data can be transmitted, then physical effects can cause this data to be falsified. That is the reason that checksums are built into the data packets. The transmitter generates the checksum and the recipient checks whether the checksums are still correct; if not, the data packet is rejected. The recipient does not have any other possibility, as the return address in the data packet could have also been falsified and therefore the recipient cannot inform the sender. 

Overruns in Routers

The Internet protocol, IP, is connectionless. Let’s assume that we have a router with 2 data lines connected, one fast line 1 and one slow line 2. If the router begins now with the packets in the quick succession from line 1 that should be redirected to line 2; the router cannot redirect the packets so fast over the slower line 2. A solution to this problem is that the router caches these packets and then sends them delayed. But the memory of the router is limited and therefore the router rejects data packets when it has received more than it can redirect.

The UDP Protocol  

The UDP protocol (User Datagram Protocol) is very simple. A transmitter sends packets, if the packets arrive at the receiver then it is good, if not, nothing further happens. Nothing is built in the UDP protocol for the transmitter to notice that the sent data packet did not arrive. 

The TCP Protocol  

The TCP protocol (Transmission Control Protocol) is connection-oriented and complex. With TCP it is guaranteed that all data packets that an application sends intact, complete, and in the correct order will arrive at the recipient.  

Simply described, it functions like this:  When the IP stack of a computer sends a TCP packet, the recipient must send an acknowledgement within a certain amount of time (a fraction of a second). If the sending IP Stack doesn’t receive an acknowledgement, because the sent packet is lost, the recipient doesn’t exist anymore, or the acknowledgement was lost, then he sends the packet again. If after a certain number of repetitions still no acknowledgement is received, then the IP stack reports this error to the application. 

Suitability of UDP or TCP for Streaming

For streaming, specifically for real time, normally UDP, not TCP, is used. If now and then a packet is lost by streaming, it is not a big problem. If however, like with TCP through the repetitions of packets, streaming doesn’t continuously function, then there will be a certain problem. 

Suitability of IPSec or SSL for Streaming

IPSec is connectionless like UDP; packets from the IPSec layer are not repeated, and therefore well-suited for streaming.  SSL is based on TCP. It is constructively built so that all packets must arrive intact, complete and in the correct order at the recipient, otherwise the cryptography of SSL doesn’t work.  

SSL is less suitable for streaming. A way out of this problem is to build an encoded UDP connection parallel to SSL and then dispatch the streaming data in this way when it is possible. This is exactly built in the HOB VoIP solution, HOBPhone. 

Practical Experience

Streaming over IPSec works well.  Streaming over SSL usually works just as well, because transmission errors are seldom seen these days. 

Author:
Klaus Brandstätter, CEO, HOB Inc.

Sources:

Microsoft
DEVELOPING DRIVERS WITH THE WINDOWS DRIVER FOUNDATION
Penny Orwick, Guy Smith
ISBN-13: 978-0-7356-2374-3
ISBN-10: 0-7356-2374-0

02.05.09 KB
04.05.09 KB
12.06.09 KB

 

The desire to work at home can become a necessity, as currently discussed reaction plans for the event of a serious influenza pandemic have shown. To guaranty business continuity for the successful operation of external workplaces, enterprises should deploy highly performant remote access solutions before a crisis strikes.

The discussion of how enterprises can maintain business continuity in the event of an influenza pandemic is not new: Already in August 2007, the Swiss pharmaceutical giant Roche announced that their emergency business plan also foresees the need for employees to have secure remote access to the company's IT system, in order to ensure business operations continuity and protect the employees from exposure to health risks. "The most important service that we have defined is the remote access of our employees to the computer systems," said Jennifer Allerton, CIO of Roche Pharma. However, a study carried out by the corporate consulting firm Mercer in 2007 showed that only 47 percent of major corporations had created an emergency plan and only 17 percent had planned a budget for pandemic contingency planning. Even if the home country of an enterprise is not directly affected, problems may nonetheless arise, as was demonstrated this May in Hong Kong: Hundreds of travelers and hotel guests were placed under quarantine by the Chinese health authorities, as it was feared they may have come into contact with just one Mexican visitor who had tested positive for the swine flue virus.

Securing Business Continuity from Outside

Whereas one usually thought of business continuity assurance in terms of secure computer centers and databases, backups and restart times, when one considers the possibility of employees being unavailable, the topic gets a new dimension: In such a case, the enterprise must follow two goals:

• The systems must be able to be remotely operated and administered.

• Employees must be able to work from home or other remote locations.

The Solution: Secure Remote Access

Corporations that want to ensure smooth business continuity even in such times of crisis when only a skeleton staff may be available on location, require a readily available, performant and easy-to-use secure remote access solution. That this also increases the attractiveness of the workplace and thus the entire enterprise, is a welcome side effect. In many cases, the use of home offices or the use of freelancers can also lead to cost reductions. The First Step: Needs Assessment The first basic question in a remote access project is whether this access, and thus the ability to work at home, should be set up only for use in the event of a crisis or whether it should be implemented as part of standard business procedure. When this has been decided, it must be decided which employees or home office workplaces are to be equipped with secure remote access. Depending on the employee's duties, the type and range of secure remote access is to be determined: From access to only their own desktop to comprehensive secure remote access to the entire enterprise network. Finally there is the question of which technology to use. Decisive factors here are , availability, performance, cost and, of course, security. The Internet can make workstation PC's and systems available from all over the world, but this brings with it security risks.

Which Access for What Purpose?

The technical prerequisites for remote access from and to home offices are already available almost anywhere: Just about everyone has a PC or laptop and uses an economical DSL connection. Laptops and PDA's can be used during business trips and, in an emergency, one can read one's e-mail from an Internet Café or a PC in the hotel lobby. HOB provides two proven solutions for secure remote access: HOB RD VPN, which uses the SSL protocol for encryption, and HOBLink VPN, which is an IPSec-based VPN.

Secure End-to-End Connection via SSL: HOB RD VPN

In the opinion of IT experts, the SSL protocol is increasingly being deployed for secure remote access solutions. HOB RD VPN uses SSL encryption to protect its End-to-End connections tot the application level, which works in every environment and in only a very few cases is blocked.

With HOB RD VPN, there is no need to install any HOB software on the client side, neither are special drivers nor administrator rights needed; the client machine only needs a Java-capable browser.

In addition to secure remote access to an Intranet, Web applications and file servers, HOB RD VPN also has powerful Java Remote Desktop clients for Windows Terminal Servers, which also require no installation on either the client or target machine. HOB RD VPN can also provide full network access with the HOB PPP Tunnel component. With this, the user can get secure remote access to any network resource for which he or she is authorized.

Full Network Access Over IPSec: HOBLink VPN

For secure remote access over IPSec, HOB has the product HOBLink VPN, which, using its "Silent Installation" feature is easy to centrally  implement and administrate. Hereby the enterprise-wide rollout is carried out via a client CD, which when started automatically installs all of the features, rules and ad-ons.

After entering user name and password, the user can logon to the enterprise network and, depending on the authorization given, directly access his or her applications and data. 

HOB GmbH & Co. KG
Marketing/Public Relations
Petra Körwer
Schwadermühlstraße 3
90556 Cadolzburg
Tel. 09103/715-284
Fax 09103/715-271
E-Mail: marketing@hob.de

Before we put a new file server into production, we make a few benchmarks for the CIFS and NFS performance. The new server was a Solaris box with huge ZFS volumes. On the Solaris server an NFS server and Samba (for CIFS) are running out of the box. Samba was configured to use our MS Active Directory for Authentication.

As benchmarks we use the following:

A program that reads files of different sizes (5GB, 100MB, 10MB 1MB) from the server share.

Different copy jobs with a 5GB file and 1GB folders with different file sizes.

If you are interested in the detailed environment, benchmark description, values and charts you can download this pdf .

For all the benchmarks we measure the time for completion and calculate the transfer rates.
To omit compression of the used protocols we used files created with /dev/urandom.

We expected nearly the same values for reading a file and copying to a local drive, since both tests do the same (copy additionally writes to a local disk and might therefore be slower).

Reading from a server share is the most common task done in the real world, so this performance has more effect in real environments.

The CIFS and NFS shares are in the same shared folder on the server.

We discovered that NFS was very fast, but CIFS was very slow. Especially when we read from the server or copied from the server. With NFS we read a 5 GB file with over 80 MB/s (about one minute), the same file has only 7 MB/s (about 12 minutes) with CIFS! All the different copy jobs from the server share to the local drive are under 10MB/s for CIFS; for NFS we are never under 40MB/s.

For the copy the files to the server jobs, NFS was also always faster than CIFS, but only by about 10 MB/s. So sending files to the server with CIFS has no such bad performance.

We were very surprised about the bad values for CIFS. To verify the results, we decided to measure another system. A Windows Server 2008 with a faster CPU and a fast storage system. The results were in the range of the Solaris NFS System. When copying to the server share, the Windows system is always faster than the Solaris system.

So CIFS is not slow, but our Solaris system is slow; maybe Samba is the problem?

To verify this we used a slower Linux box with Samba and NFS. On the Linux server we have also nearly 80 MB/s for NFS for the 5 GB file. If we use smaller files the transfer-rates are slower compared to our Solaris NFS server. As expected, asynchronous NFS was a bit faster than synchronous NFS. For the CIFS share we measured 37 MB/s. For the most benchmarks CIFS and NFS have comparable results. With some benchmarks CIFS wins, with others, NFS.

As expected Samba is not slow at all.

Back to our Solaris system, we discussed the next steps to find out why we measure such bad values for CIFS. First we tried some performance parameters in the Samba configuration. This gave us minimally better results. This made us think, maybe our Active Directory authentication is the problem, so we decided to use local authentication for Samba. This gave us marginally better results. After asking a Linux specialist in our IT Department to take a look at this, he found the problem (high log level for Samba) and solved it. Now Samba on the Solaris box is comparable to the Windows 2008 Server. As our tests are now finished, we can say the winner is NFS: If you are reading from a server share, the results are slightly better than for CIFS. When writing to a server share, CIFS is clearly faster for all writing benchmarks.

If you are interested in the results with charts, please download this pdf .

HOB RD VPN is a remote access solution based on SSL. The SSL part is quite old, it was first developed for the 3270 data stream to securely access IBM mainframes. Later it was extended to support RDP, then HTTPS for the HOB Web Server Gate and, finally, for tunneling of PPP. The SSL part of HOB RD VPN also has the product name HOBLink Secure. We believe when HOB started the development of its SSL solution, the popular OpenSSL was not yet available.

So over time there was the question at HOB: Should we support SSL Accelerator Cards?

First I have to mention that we at HOB work with the latest servers from leading vendors. We always buy the models with the highest clock speed. The HOB development people should not waste their time working (meaning compiling and debugging) on slow machines.

We acquired some SSL Accelerator Cards as test equipment and got them working. These cards were connected to the PCI bus of an x86 system.

But the results of tests we made were quite disappointing: When calculating the asymmetric RSA key, the SSL Accelerator Cards gave some advantage over the solution in pure software. But the symmetric encryption algorithms, mainly the currently most widely used AES algorithm, did not give an advantage over the software solution. Also, one or more cards were even slower compared to the pure software solution.

The asymmetric RSA key is calculated only once, at session start. The key found may also be re-used between two partners having one or multiple SSL connections between them. So processing of symmetric encryption is far more important compared to the calculation of the asymmetric RSA key.

We believe the reason for not getting more speed out of the SSL Accelerator Cards is the following: The CPU, when an SSL Accelerator Card is used, still has something to do: it has to send all the data down the bus, then the card will process, and afterwards the data is sent over the bus again. Whether there are cards which directly access the main memory is something I don't know.

The HOB SSL suite contains all major encryption algorithms including AES with a 256-bit key length. The HOB SSL also contains, as an option, compression. Netscape defined the original SSL protocol, and in the handshake they already put in parameters for compression. So HOB included compression, but we do not know of any other vendor who included compression as well. Tests have shown, for compression there are about as many CPU resources used as compared to symmetric encryption. But the SSL Accelerator Cards do not include compression. We have seen hardware that does compression. But, when comparing the compression ratio with software solutions, the hardware compression does not compare well. The reason for that is, that in compression algorithms there is some fine-tuning possible in software. Doing the same in hardware would be too complicated. So we found out compression should be done in software as well.

At HOB, we have successfully tested the WebSecureProxy, the SSL gateway, with 10,000 simultaneous sessions; both on Windows and Linux, and using an x86 CPU on mid-size servers. No SSL Accelerator Card was necessary to reach 10,000 simultaneous SSL sessions. Each of the sessions was run with simulated RDP traffic where the user neither permanently sends nor permanently receives data from the server.

We believe, on big machines, even more than 10,000 simultaneous sessions are possible - without an SSL Accelerator Card. And HOB RD VPN supports clustering as well.

The HOB WebSecureProxy was designed with heavy loads in mind, and it can keep any number of CPUs busy without giving delay to the users.

The HOB SSL encryption routines have been examined by the BSI, the German Bundesamt für Sicherheit in der Informationstechnik. The HOB SSL encryption routines got certified under Common Criteria. In the course of this certification, HOB made a large number of compatibility tests with other SSL solutions.

If the HOB customers would use SSL Accelerator Cards, there would be extra cost for the cards. Also, as hardware can break, our customers would need spare parts.

With the HOB solution, especially with the Unix-based OpenSource operating system HOB SCS, when there is a hardware problem you go to the nearest PC dealer, get a server out of the box, install the software and the problem is fixed.

I believe today we get a lot of processing power out of modern CPUs. These CPUs have many cores today. So spending money for fast CPUs is better compared to spending money for SSL Accelerator Cards.

12.09.08 Klaus Brandstätter

How many servers will we need for a certain application?

This document provides some insight into the servers necessary for WTS (Windows Terminal Services) or VDI (Virtual Desktop Infrastructure).

In the old days, companies had just a single mainframe and certain applications running on it. As CPU load generally is the primary bottleneck, the people responsible for the mainframe just looked at the CPU utilization and, when it was over 80%, they knew they had to buy a bigger one. When paging was too high they had to buy more memory.

Today we can run applications in many ways, and these ways all have different needs for computing power and memory.

First we look at desktops. As Windows Vista has been available since early 2007, most users found out running Windows Vista with less than one gigabyte of memory is quite slow.

When we have desktops, these should share their data. This is typically done over a file server. I have heard people say a modern server can handle 5,000 simultaneous users when this server is used as a file server.

How about Terminal Services? At the moment of this writing, most terminal servers are used by around 50 users. 32-Bit operating systems are mostly used; the problem with 64-Bit operating systems (Windows) is that not all drivers are available in 64-Bit versions. As companies have more users, load-balancing is used to connect all the users to multiple servers.

But Windows Server 2003 and Windows Server 2008 can handle many more concurrent users. In the paper on

http://www.microsoft.com/windowsserver2003/techinfo/overview/tsscaling.mspx

Microsoft says they have tested several hundred users on hardware dated 2003. As today we have more advanced hardware with fast CPUs, many cores and lots of cheap memory, I believe running terminal servers with hundreds of users is no problem. Of course, 64-bit hardware and software is needed in this case.

But some key points should be kept in mind: Windows, as well as other modern operating systems, does paging as a default configuration. Paging means, memory not frequently used is written to the page files on disk, so less memory is needed. What happens if a machine has enough memory so that no paging is needed? As Windows always tries to have some memory space available for when new applications are started, it still writes pages to disk and frees the internal memory as it is not needed. The problem today is that the gap between CPU speed, memory speed and disk speed always widens. And as we have more memory, the page file on disk gets bigger and it takes even longer to read in the requested memory pages when needed.

We have a big WTS in use for our developers, running MS Visual Studio and Eclipse. Our WTS is sometimes up for many months and users do not log off. In the evening they disconnect their RDP session. When they come in the next morning they start their RDP client and can continue to work where they left off the day before. Our users find that straight-forward. When we had paging enabled, and when applications had not been used for maybe several days, the users clicked on the icon in the task bar and had to wait maybe 10 minutes until the application was paged in and the users could work again. Sometimes the application did not show up any more, even after hours. All these problems disappeared when we turned off paging in the Windows operating system. Without paging, our system always immediately responds to every action users make. It's a great system!

I can give the following advice: Buy so much memory for your servers that paging can be disabled. Memory is cheap and will get even cheaper. Disable paging by configuring Windows accordingly.

As you have no more paging, you do not need fast disks any longer. It is sufficient to buy big, cheap SATA disk drives instead of buying the faster but smaller and more expensive SCSI disks.

Let us talk about VDI or desktop virtualization. Using VDI means you have servers running virtualized single-user operating systems such as Windows XP or Windows Vista.

When VDI is used, multiple copies of the (guest) operating system are simultaneously in memory, so much more memory is needed. Remember that you should not have less than one gigabyte for every Windows Vista. And remember you should have paging turned off. When running VDI, I recommend you disable paging on the host level, but paging on the guest level will still be needed (otherwise you would need just too much memory). If you have a Windows Vista system and give it only one gigabyte of memory without paging, you will not be able to start many applications.

So when we have a server with 16 gigabytes of memory, we can only have around 16 simultaneous Windows Vista guests running.

So, compared to WTS, VDI needs much more hardware resources. However, there are still occasions where VDI is more suitable than WTS. And hardware keeps getting more powerful and cheaper, so VDI, in some cases, becomes more attractive.

13.08.08 Klaus Brandstätter

Recently I was surfing the Web and found something about my company, HOB, at Wikipedia. In the German Wikipedia I found something about 3270 which I believe does not cover the technical background. And also, I think there is something wrong: The article says Attachmate produced 3270 terminals in the past. I remember Attachmate produced 3270 coax cards, but never real terminals.

My name is Klaus Brandstaetter, I was born in 1954, and since 1981 I am CEO of HOB Germany, which was deeply involved in the 3270 market. As I know much about 3270 I decided to write something about 3270. As 3270 was a billion dollar market in the 70's and 80's, and 3270 is still in use today, there is much to say. I will concentrate on the important facts only, but still this will be a big article.

IBM with the /370 mainframe system was the dominant IT company in the 70's and 80's. At IBM, each product they sold had a four digit number, so the terminal they developed for the /370 mainframe got the number 3277. The first display had a very small screen displaying only 12 rows with 40 characters. The terminal had a white cabinet made from sheet metal. This was called Model one, and there was also the Model two which had the same cabinet but a bigger screen of 15 inches displaying 24 rows with 80 characters each. The characters were displayed in green on black background. Some say WYSIWYG, in the case of 3270, stands for "What You See is what IBM Gave You." Each 3277 terminal was connected over a coaxial cable to a control unit. The transmission speed of this coaxial cable was at first something around one megabit per second. Later, with the next generation, 2.3 megabits per second were achieved. A terminal did have some logic, but no CPU; each terminal, of course, had a screen buffer (memory) where the characters to be displayed were stored.

If each terminal would have been connected to the mainframe directly, each keystroke would have generated an interrupt on the mainframe. At that time, there was only limited computer power, so it was not possible to process a lot of interrupts in a given time. So IBM chose to connect each terminal to a so-called control-unit. The IBM part number of the first control unit was 3272, later 3274 and 3174 followed. The first control units had a CPU, but as memory was very expensive the CPU used the screen buffer of the terminals as memory. Commands which access the memory on the terminals were exchanged over the coaxial cable between control unit and terminal. The terminals that worked that way were also called CUT, Control Unit Terminal. Each control unit could handle up to 32 terminals, later a control unit could handle up to 128 terminals. The control unit was connected to the mainframe (channel) with a so-called Bus/Tag cable. This cable had eight parallel wires for the data and another eight parallel wires for the /370 channel command. A control-unit could also be used remotely: typically used were fullduplex lines with a bandwidth of 9,600 bits per second. Can you imagine 32 users today working over a single telecommunications line with just 9,600 Bits per second? But in the 80's this was common and the users did not complain. It is also worth mentioning that 3270 terminals, especially the 3277 one, could also be connected to an IBM /3 computer, which was less powerful that the /370 mainframe. The IBM /3 was the ancestor of what later would become the /34, /38, /36, for a long time AS/400 and what is now called the i-Series. With the IBM /3 computers, 3277 terminals were used with coaxial cable, but the successors got 5250 terminals with a more sophisticated protocol, connected over twinax cable, which is also called twisted pair.

For the 3270 terminal to work, the software in the mainframe had to use the 3270 protocol. Typically in the 3270 protocol the EBCDIC character set was used. A terminal could display up to 192 different characters, the remaining byte encodings were orders and attributes. The application in the mainframe sent either a complete screen or a part of it, mixed with orders. Such orders included setting the cursor, moving to other locations on the screen and orders to fill in attributes.

Such attributes separated the screen into different fields, a part of them editable by the user, others were protected. When the mainframe application sent data to the screen, the user could edit the page displayed and navigate around on the screen. At all this was independent of the host, the mainframe. When all the page editing was done, the user had to press special keys, either Enter, PFx (Program Function) or PAx (Program Attention), and only then was all edited text sent to the mainframe, to the receiving application.

In this way, computers with, compared to today, relatively small computer power could handle the traffic of many terminals, in some installations thousands or even tens of thousands.

This type of processing is similar to what we got with HTML / WEB 1.0, and is called transactional processing.

When we look back at the history of 3270, the first generation of terminals was 3277, 3275 and 3272 as control unit. After that, the next generation consisted of the terminals 3278, 3276 and 3274 as control unit. With the 3278 there was the model 2, displaying 24 x 80 characters. Additional new models were added: model 3 with 32 x 80 characters, model 4 with 43 x 80 characters and model 5 with 27 x 132 characters. Model 5 displaying 132 characters in a line was useful to view print output, since printers at that time usually printed lines 132 characters wide. All models had an additional line to display status information. All terminals had the capability to switch to the model 2 mode, displaying only 24 x 80 characters. There followed the color terminal 3279, which could display the characters in up to seven different colors. A special and very expensive terminal, the 3279G, could also handle graphics. Graphics were built by loading special characters with pixels in the desired colors and then addressing these characters in the data stream sent to the terminal. It should also be mentioned that as a base functionality, most of the IBM terminals had an additional, built-in character set called APL characters. APL characters also could be entered from the keyboard. APL stands for A Programming Language, and APL characters were made from the Greek Alphabet.

Besides the graphics addressable through loaded characters, IBM later added vector graphics.

In the 3270 family of terminals, IBM had many different models, for example 3277, 3278, 3178, 3180, 3179, and so on. The different generations of control units were called 3272, 3274 and at last 3174. There were also terminals with a small control unit built-in, like 3275 and 3276. Many different printers were sold, some of them with the number 3286 or 3287. The printers were connected to the control unit over coaxial cable just as the terminals. For the software, IBM tried to have printers that were programmed similarly to a terminal, sending more than one line to the printer in a chunk of the data stream.

IBM sold millions of the 3270 terminals, mainly from the 3278 model and later models. But there was also competition from other manufacturers, such as Memorex, Telex, HOB, Lee Data, Ericson, Nokia, MDS, ADI and Fujitsu. Memorex and Telex later merged into one company. Altogether there were about 15 different vendors producing 3270 terminals. Most just copied IBM's models, some had unique add-ons. Only HOB succeeded in manufacturing a 3270-compatible terminal with graphics support. Some of the vendors also built their own control unit and used a different cabling schema. The company McData was very successful building 3270-type control units.

The market for 3270 terminals was lucrative until the middle of the 90's. By this time standard PCs had already taken over the business with hardware and software emulating 3270 terminals.

Look at this market now: IBM sold the first IBM PC in August 1981 after just 9 months of development time. IBM then, for a certain time, dominated the PC market. Soon after IBM brought out the first PC, the company IDEA developed and sold a so-called Irma coax card, fitting into the IBM PC with the standard bus. This also included software running in MS DOS. Hardware and software both connected to an IBM (or compatible) control unit, and the user could do what he normally would have done with a hardware terminal. This solution also included file-transfer in both directions between the IBM mainframe and the PC.

After that, IBM also developed such a coax card, and other manufacturers did the same. The emulation software from IBM was called Personal Communications or in short, PersCom. Let us name some of the other manufacturers and their products:

Attachemate with Extra!

Wall Data with Rumba

WRQ with Reflection

HOB with HOBLink 3270, later HOBLink Terminal Edition

At the end of the 90's, 3270 emulation was a big market and about one hundred companies had developed such software.

There also are 3270 emulations written in Java, HoD = Host-on-Demand from IBM or HOBLink J-Term (Java Terminal).

Software in use where the 3270 client is connected to: IMS Information Management System CICS Customer Information and Control System TSO Time Sharing Option and many others.

Software that generates 3270 data stream with graphics includes IBM GDDM (Graphical Data Display Manager) and software from SAS.

In the beginning, the 3270 data stream was sent over simple protocols such as channel-attached or a family of protocols called BSC (binary synchronous communication). Around 1970, IBM invented VTAM and SNA, System Network Architecture. SNA dominated the network protocols in use for a long time. Nowadays SNA is only used inside of the IBM mainframes, all real network connections are done over TCP/IP. For 3270 emulations this protocol (a type of telnet) is called TN3270 or TN3270E, defined in several RFCs.

Prominent people of the IT industry had made bets that the last mainframe would be switched off December 31st, 1999. As we know, this did not happen, and mainframes are still in use by many big organizations. And the 3270 protocol is also still in use.

Some time after the year 2000, an IBM marketing campaign was saying that every day there are still more 3270 transactions than there are transactions over the World-Wide-Web.

12.08.08 Klaus Brandstätter

The HOB WebSecureProxy is the security gateway for many organizations. It is used to access internal applications over the Internet.
The HOB WebSecureProxy is configured through one (and only one) XML configuration file. XML has the advantage that it is human readable. It is the proven way to simply exchange information between the administrator and the machine (computer).
There is a Java based configuration tool which is used to enter the necessary information. But this XML configuration file can also be edited with every common text-based editor.
The XML configuration file can be viewed with Web Browsers and their built-in XML functionality, the hierarchy of the definitions can be seen.

We all know that sometimes administrators call all users of certain services and tell them they have to leave the application at a certain time because the configuration is going to be updated then and the application will have to be restarted.

The HOB WebSecureProxy can dynamically update its configuration by reading a new version of the XML configuration file.
This means, users that have logged on before the configuration update keep their old configuration until they log off.
Users who log on after the configuration update automatically get the new parameters. The service is not interrupted.

The problem of users having a part of their configuration parameters from the old configuration, and the other part of their configuration comes from the new configuration does not exist.

Which techniques are used to enable this scenario?

In Windows the WebSecureProxy is the program IBIPGW08. IBIPGW08 automatically gets notified when the XML configuration on disk (that was used when IBIPGW08 was started) is changed and then reads in the new parameters.

In Unix and Linux the WebSecureProxy is the program NBIPGW08.
When the XML configuration has been changed, the administrator can start a new instance of NBIFGW08. The new instance of NBIPGW08 notifies the already running old NBIPGW08; the already running old NBIPGW08 closes its sockets which listen for incoming new connections.
Now the newly started NBIPGW08 can listen on the same ports again and users who log on from now on automatically get connected to the newly started NBIPGW08.

The already running old NBIPGW08 automatically exits when all users have logged off.

Security Risk of Applications Listening on Well-Known Ports

In Unix and Linux only applications running at superuser level can open the well-known ports.
The HOB WebSecureProxy normally listens on HTTPS port 443; this port is one of the well-known ports.

But for security reasons it is less critical when the WebSecureProxy NBIPGW08 runs on a normal user account.

To solve this problem, HOB has developed the listen-gateway NBIPGW12.
The listen-gateway NBIPGW12 is a small application which should run on superuser level and can then open the well-known ports.
The listen-gateway NBIPGW12 needs only little configuration, this can be given in the command line when NBIPGW12 is started.
The HOB WebSecureProxy NBIPGW08 now runs on a normal user account and creates a Unix Pipe (FIFO) to NBIPGW12. NBIPGW08 over the FIFO sends encrypted commands to the listen-gateway NBIPGW12, such as open a port for listen. The listen-gateway NBIPGW12 then opens said port for listen and forwards all incoming connection requests to NBIPGW08 over the FIFO.

In this way, NBIPGW08 does not need to run as superuser and still can open well-known ports.

1. The Problem

On the serial ports of PCs, asynchronous communication is mostly used. This means, every piece of information, which is normally one byte with 7 or 8 bits of information, is sent individually. There are start-bits at the beginning of each character and there are stop-bits at the end of each character. Information sent mostly contains multiple characters, forming a block.
The problem now is, that neither the hardware nor the software driver can know how many characters form such a block.
We discuss here how applications handle this type of traffic.

2. Applications We Have Seen

We have seen applications of other vendors and how they work. The have a buffer of a certain length, for example two kilobytes. They set a very short timeout and receive data in a loop.
In Windows, ReadFile() is done, giving the buffer and its entire length.
The ReadFile() returns when either the entire buffer has been filled by the driver or when the timeout has elapsed.
Now in the loop, there is mostly no data received, and the ReadFile() returns after the short timeout saying it has received nothing.
So these applications constantly give a certain load to the machine they are running on. Another disadvantage of this technique is, that there is also a delay before the application gets the data that have been received, because the buffer normally does not get filled; there are just some bytes received.
This delay is theoretically half of the time of the timeout set.

3. HOB Approach for Receiving Data with the Serial Interface

In the HOB approach, the serial interface is set for no timeout, or a very long timeout. When data is received by the application, ReadFile() is started, giving a buffer of one byte length. Then the ReadFile() operation returns each and every time a single character has been received, and only then.
During times when no data is received over the serial line, this application does not consume any CPU cycles.
When data are received, CPU load is higher, since there is a context switch for every byte received. When data are received, they can be immediately processed by the application without any delay.