Re: I-Net protocol stupid design: a performance issue for networking.

Could you give us a list of the alternatives to I-net? Bryan Tonnet <batonnet@zeta.org.au> wrote in article <5qur62$tf1$1@godzilla.zeta.org.au>... > In <01bc9550$ad416e40$a34efac2@philippv> "Philippe Verdy" <verdy_p@msn.com> writes: > > >I have been requested by one of the customers of the company for which I > >work about networking performance that I did not detect before during > >development until I put our software in the production process. > > >After some searches, I have found that the most important problems lays in > >the I-Net protocol used, from version 5.0 to the newest 7.22 I-Net > >implementation I use since a few months: > > > INFORMIX-NET DOES NOT COMPRESS TRANSMITTED DATA TO THEIR > > ACTUAL LENGTH, BUT SEND THEM WITH THEIR MAXIMUM LENGTH, > > PADDING DATA WITH UNNECESSARY NULL BYTES, EVEN THOUGH > > THE PROTOCOL HAS A PREFIX BYTE FOR THE ACTUAL LENGTH. > > [I-Net expose snipped] > > Is there some specific reason you're stuck with I-Net and cannot use an > ODBC driver with a native database driver? There are a few of them about > nowadays, and I tend to take I-Net out of the loop if at all possible > (admittedly, this is usually for security reasons rather than performance). > > Don't know if this will solve your problem, but my experience is that it > makes life much simpler, much more secure (ie a little bit rather than > nearly none), and slightly better performing. > > > -- > Bryan Tonnet > batonnet@phase4.com.au > >