Re: I-Net = I-Connect ???????

In article <5r0c33$agd@cssun.mathcs.emory.edu>, CPeries@dynasty.com ("Peries, Chaminda") wrote: > > > Hi ! > > Does I-net & I-Connect refer to the same software ? > If not what exactly is the difference ? > > Thanks > > Chaminda I-Net is the native networking protocol used between any client and a Informix server. This is the protocol which is used over the TCP port, which consists in two implementations: onsoctcp and olsoctcp. I-Connect is a native client library interface that uses the I-Net protocol. It is mainly designed for ESQL programs, or any third-party drivers written to use the ESQL API's. CLI is another native client library, based on the ODBC standard. It is directly used with a documented API set of functions, which can be directly called to support the ODBC standard (even under Unix), or can be directly used to implement an MS-compliant ODBC driver for Windows clients. As far as I know, both interfaces use I-Net, which is the only protocol available for networking on the server side. So any Informix driver will use I-net implicitly, whever they are written using ESQL, CLI, or any other I-net compliant third party library. I have been told by others, that ESQL/C was performing bad, and that I should use another connection API, for example a good client ODBC driver. However, this does not change the fact that I-Net is still used over the network. It has many limits, and is partly of a poor design (network congestion problem). The only substitute to I-Net is to have the server support another networking protocol, by running another connection service, written using ESQL/C or CLI, and which connects directly on the server itself using local networking (via I-Net protocol of course !), using onsoctcp, olsoctcp, or one of the supported IPC protocol (SHM). Then you will connect your clients using your proprietary networking interface. That's what I have been ask to do: I implemented my own networking protocol, rewrote my own API to connect to Informix servers, and implemented all the functions that our clients need using our own networking protocol. In that case, clients no longer need any Informix I-Net software, no CLI and no I-connect. Of course, they cannot run any standard tools written for I-Net. But I have the project of writing a local networking server running on the client, (to which they can connect locally using a standard Informix protocol compliant to I-Net), but that uses our own networking protocol instead of I-net to query the server via our own networking service. For now, I prefer implement the core-level of ODBC API for our networking protocol, and will extend it further when our clients need them. The advantage of this solution: now the networking protocol uses data compression on the network, implements a more soft interchange between clients and server. I want to make it as robust as possible to support many clients with good response times. Also, I have written the protocol to support the same level on other database services, with a reduced set of portable functions, mainly for Sybase and Oracle servers. Later, I will be able to have this proprietary server run locally on a Sybase server using the DB-Library, and on a Oracle server using SQL*Net services. You may argue that my clients do not connect natively to the Informix server. However, the advantage of better networking performance, and small processor overhead, is much more important than using a bad performing native networking: my networking server is very small, and has nearly no impact on the server (it does not implement SQL itself, but passes it transparently to the actual server which does all the job). And now clients written directly for our protocol are much more simple to install, because they do not require complex API to interface with our networikng server, just a standard TCP protocol stack, so you can consider our clients as if they used an efficient native interface for our own networking server. In addition, the client-side of our protocol has been written to be portable under Windows 3.x, Win95, OS/2, Macintosh, Unix. Once completely tested, it will be deployed over our applications (we just need to recompile the database interface library they use, without changing the rest of the code). Finally, it solves one of the problems with I-Net: the protocol cannot be used over the network to do many operations that are available with Informix only on the server itself: storage management (tablespaces), database management (creation, save/restore). Moreover, it adds integrated SQL support for BLOB's, and this management, simplifying installation scripts (no more complex and non portable shell scripts to write, just a SQL script for all the operations we need). This protocol was written only for our needs, so I don't think it would solve all the problems for any client, it is just what we needed for our applications, so it was simple and fast to write, and made us gain much time in the overall development, due to the added and simplified functionalities. If interested by such development, contact me. -------------------==== Posted via Deja News ====----------------------- http://www.dejanews.com/ Search, Read, Post to Usenet