From: MERC::"uunet!CRVAX.SRI.COM!RELAY-INFO-VAX" 20-JUL-1992 10:05:54.24 To: info-vax@kl.sri.com CC: Subj: TCP/IP software evaluation There seems to be a lot of talk lately about the evaluation of different TCP/IP packages for VAX/VMS systems these days. I have had experiences with Wollongong and recently I had the opportunity to do a project using UCX. Well, I'm not sure if I should call it an opportunity... I never did any programming with the Wollongong software, but it was just not very reliable. Some days it would work and others it wouldn't. Some times it would hang while connected to another system. Our system manager played with the parameters to get Wollongong to be more reliable, but nothing could cure it. I also heard that the documentation stunk, I have not personally seen it though. Just today I finished a project which used UCX V1.3. If you are wondering why we used UCX, it is because it comes to us free with every VAXserver we buy. (We have an OEM agreement with DEC, so I'm not sure if *every* VAXserver comes with the appropriate license.) Anyway, from a system management and user point of view, UCX V1.3 is pretty bullet proof. It never hung and always ran flawlessly. For some of you, UCX V1.3 may be a little limited, but we only use it for programming, FTP, and an occasional telnet. We have no need for any of the other features provided in most other TCP/IP packages. I have heard that V2.0 of the TCP/IP services offerred from DEC should have more of the features that most people are use to getting with other TCP/IP packages. Nevertheless, my programming experience with UCX was less than enjoyable.Though, it should be noted in large letters and underlined a few times that the whole project was written in the VAX assmbley language. We do not have a C compiler nor would management spring for one, but the project had to go on. If it was written in C, I would probably have had an easier time with it. Of course, I would not have been able to do some of the things as easily as I did in MACRO32. Documentation: You really have to watch out for the documentation. If you are going to use it, you have to realize that it was not written by a VMS person or someone who is familiar with VMS manuals. I'm talking specifically about the $QIO interface. Some arguments can be either input or output depending on various things like the phase of the moon, and it will still have an access method of read only. The access method for an argument can be read only even though later buried in the description it states that it will write to that location after all. In addition, descriptors are not documented like you would think. If a descriptor describes a location that will be written to, its access method is still most likely to be read only which is contrary to typical VMS documentation. I'm not sure if this has been fixed in the V2.0 documentation, but I have heard that the amount of documentation has been greatly expanded. Programming Examples (supplied software): Many of the examples will work between two VAXes running the UCX software, but they will not work with a VAX and another Unix box. This is because the hard coded port numbers need to be in big-endian format. If you switch the bytes in the Macro or C examples that you plan on running on the VAX/VMS side, the examples should work. Programming: There are several problems with programming UCX V1.3 using the $QIO interface. 1) Many of the IO$_SENSEMODE operations will either return no useful information (all zeros) or an error that you never can correct. This is the only way to get some types of information about your environment. Unfortunately, it never worked as documented. 2) Data that you would expect to be read only are tested for read/write access; consequently, you have to change some of your PSECTs to read/write instead. Many regular system services do not have this restriction. 3) Many $QIO calls have optional arguments. Unfortunately, the documentation is not clear about which are or are not optional. After using trial and error, you will be able to find which arguments you should use, which ones you must use, and which ones you must not use. 4) Some standard C functions do not have a documented equivalent $QIO call. Example: I needed to get my Internet address to filter out my own broadcast messages. I wanted to ask the system on the fly so that I could run this program on any VAX/VMS system without knowing my particular host name. I used IO$_SENSEMODE using an I/O control function (IOCTL) to get the interface address, but it always complained about a missing ARP table entry. I even inserted an ARP entry into the table, but it did not help. Then, I used IO$_SENSEMODE to get a local socket descriptor. The local socket descriptor did contain the port number that I was using, but the Internet address was zero. After experimentation, I found that IO$_ACPCONTROL could get the Internet address of a known host. But there was not a documented $QIO call which was equivalent to gethostname(). In fact, gethostname() does not exist until V2.0. Currently, I am translating the UCX$INET_HOST logical to get the host name. After passing that information into a $QIO call using IO$_ACPCONTROL, I was able to get my Internet address. I am not sure if the developers left that logical for me to use, but it does get the job done. 5) I have found that TCP/IP connections never timeout under some types of error conditions. If the Unix system is rebooted or turned off, the process using TCP/IP will hang forever waiting for input data. 6) In V1.3, you can maintain more than one connection with a single host only if you establish and use the connections within the context of one process. Depending on the complexity of the program, this can be extremely difficult. Being that I was doing double bufferred I/O with a TCP/IP port and direct $QIOs to a disk file, this was a little much to ask. There are ways to get around this limitation, but it is not a clean solution. I have heard that V2.0 will directly support multiple connections with a single host that are not restricted to a single VMS process. 7) The last problem I had which is not UCX specific is the fact that you have to potentially do an infinite number of reads to receive all of the data that you need. I reailize that this is the standard TCP/IP way of doing things, but it just seems very inefficient. Polling is such a horrible method to use on a multi- tasking machine. In V2.0, TCP/IP services provides a $QIO read function which will allow you to wait for all of the data that is needed even if it has not been entirely received. This is a much better solution. I am not sure if standard C calls provide any such thing. After having said all of this, UCX does have some good points. After you get beyond all the programming hassles, the package provides a very stable environment. (I wish non-existent connections would timeout, but you can get around this as well.) In addition, I was able to develop some asynchronous read routines using the $QIO interface which allowed me to do double bufferring. I do not believe the standard C calls allow for this. I realize most people program in a sequential manner these days (read, process data, write); but by overlapping the reads, writes, and data processing, you can significantly increase productivity. In addition, I was quite impressed with the data rates. I was only using a VAXserver 3600 (KA650) with a DELQA and was able to get 240Kb/sec. If I allowed the program to eat the CPU alive, I could get 390Kb/sec. I only have ever seen about 100 to 150Kb/sec using DECnet. Of course, the constant TCP/IP polling has a big down side. Walter H. Dick, III WHD0675@RITVAX.ISC.RIT.EDU NOTE: My opinions are my own. P.S. If you require any UCX help, knowledge, and/or programming; I am available on contract.