Re: 4GL 4.11 frontend via network to 7.30 backend

Richard Spitz <richard.spitz@ana.med.uni-muenchen.de> offerred: +from many discussions in this group and also from the manuals, I always +got the information that 4.x and 5.x frontend products (like 4GL +or ESQL/C) can only communicate with 7.x backends (like my brand- +new IDS 7.30) via the performance-eating "relay module". For this +reason, it was strongly advised to use at least 6.x frontends or +the new 4GL/ISQL 7.20. Why do you refer to the relay module as "performance-eating"? It is a relatively lightweight process that does little more than transfer messages between the client and the server. You need to understand that 5.x and earlier tools communicated with a server by spawning the server process and communicating with it via vanilla pipes. When the server was remote, a local server process was still spawned which served to simply shuttle those messages. The relay module was developed to provide all the functionality needed in those cases with none of the additional overhead and process size of the normal server processes (sqlturbo and sqlexec). +I've asked the question before in this group, but received no answer: +Is the above true also for socket connections via TCP/IP, or only +for situations where frontend and backend run on the same machine? It is true for both. 5.X and earlier clients do not know how to talk to the network directly**. + +I just tested a 4GL 4.11 program running on one machine with I-Net 5.10 +installed against another machine with IDS 7.30, connected via LAN +and using TCP/IP. I was surprised that this worked instantly, and +no relay module was used. Performance was not noticeably impaired. +With "netstat", I could see a connection on the "sqlexec" port. Instead of the relay module, you were running sqlexec on the client side, which is a much larger process due to all the functionality needed to access a database. The relay module has all that stripped away. I suggest you try benchmarking an app using the r/m with one using your above method and see what the differences are. **Actually, that isn't exactly true. At least for a while, there was an undocumented env variable that could be set to eliminate any and all client side processes other than the app itself. Using it caused the sqli lib to talk directly to the network. I don't know why this was never officially productized, and for the life of me I can't remember the name of the variable anymore. It was probably removed from the code at some point. Dave ** Dave Kosenko <davek@summitdata.com> ** Director of Training Services (732) 469-4070 ** Summit Data Group (an Informix Authorized Education Center) ** Find my advice useful? Let me teach you everything I know about ** Informix. Sign up for OFFICIAL Informix training at SDG. ** For details, see http://www.summitdata.com/training