Would this change then allow thousands of simultaneous connections, like
Oracle boasts about?

[Apologies here because I know I'm treading on ground I am not familiar
with.]
Maybe another way to solve the limited connections problem is through
pooling, and background multiplexing of connections, so that even if you
only have a limited number of actual sockets, you can accommodate tens of
thousands transparently (because the server actually disconnects and
reconnects long running connections and transactions in the background).

Joseph Alba
jalba@...



-----Original Message-----
From: Ann Harrison <harrison@...>
To: IB-Architect@egroups.com <IB-Architect@egroups.com>
Date: Wednesday, May 17, 2000 1:09 AM
Subject: [IB-Architect] Engineering project description

>I'd like to describe a late change that is being introduced
>into V6 and the way decisions were made about the necessity
>and the architecture of the change. This time, the discussion
>was face-to-face in the InterBase engineering group. When
>InterBase is open source, this process will occur on the
>developers' list.
>
>An InterBase VAR called because a customer had gone live with
>an application and had got an error (fopen failed) with about
>249 clients connected to the database. The platform was Solaris
>and the customer estimated that the max load would be about
>400 clients at a time.
>
>Identifying the problem was reasonably simple*. Solaris uses
>a byte in its file descriptor where a word or a long word
>would be better. The descriptor is used only for buffered
>I/O, but it shares a number space with connected sockets.
>The socket identifiers can go higher in the number space, but
>numbers are allocated smallest first, and reused. Once the
>first 255 numbers are used, all fopen calls fail. This is
>a well-known characteristic of Solaris.
>
>Interbase uses buffered file I/O for writing the log file,
>for reading hosts.equiv and the password file, for debugging
>messages, and for external tables.
>
>We considered declaring this an operating system problem or
>an application design problem. Neither solved anyone's
>problems. SUN isn't about to change their operating system
>and the customer's application design ... well there was
>resistance to change. Nor could the problem be delayed
>to a later release.
>
>We considered performing all the fopen's at server startup
>so those files would be guaranteed low numbers. Debugging
>printf's might fail, but how often does one debug with
>250 clients attached? However, changing the timing of
>file opens involved more code changes than seemed prudent
>at this stage of the project and having external tables fail
>randomly was not acceptable.
>
>Our Unix guru mentioned that the BSD stdio routines have a
>compatible license, work on Solaris, and eliminate the problem.
>The question was how to integrate them with our code. There,
>the goals were:
>
> Keeping the code maintainable - meaning that things should be
> what they seem to be - so we would not change "fopen" to a
> macro that expands differently on Solaris than other platforms.
>
> Keeping the change simple. That ruled out writing our own
> buffered file I/O or changing to open/read/write generally.
>
> Minimizing in-line ifdefs.
>
>The solution we chose was to replace all references to stdio.h
>with ib_stdio.h, and all buffered functions from <func> to
>ib_<func>. Those changes are pervasive but mechanical. Ib_stdio.h
>will define the ib_<func>s as macros that expand into the normal
>stdio calls & macros on most systems, and macros & calls to the BSD
>equivalents (renamed) on Solaris. We will consolidate the BSD stdio
>routines into a single module and include it in our Solaris builds.
>
>
>Ann
>
>
>
>
>
>Ann
>
>* Well, simple if you have Unix guru's on staff.
>
>
>------------------------------------------------------------------------
>Was the salesman clueless? Productopia has the answers.
>http://click.egroups.com/1/3019/4/_/830676/_/958496618/
>------------------------------------------------------------------------
>
>To unsubscribe from this group, send an email to:
>IB-Architect-unsubscribe@onelist.com
>
>
>