| Subject | Re: AW: [firebird-support] CS or SS in firebird embedded? |
|---|---|
| Author | Helen Borrie |
| Post date | 2004-08-30T13:10:55Z |
At 01:24 PM 30/08/2004 +0200, you wrote:
Superserver and a client rolled into a single library.
On POSIX, you have the ability to connect an application directly to an
instance of the Classic server. (the xinet daemon listens for connections
and flashes up an instance of the server for each client connection). For
this direct connection, you use the client that is named libfbembed.so. So
it's more akin (logically) to the IPServer connection on Windows which,
confusingly, is not available for Classic clients on Windows.
The most likely use of this libfbembed client is for creating server-based
apps using Embedded SQL - hence the word "embed" in its name. Yeah, I had
one of my many famous arguments with N. Samofatov about this renaming. It
works fine for local client apps not written in ESQL, too. I've got apps
using it that were written in Kylix, though never load-tested. Kylix
server apps are NOT light in weight!!
The remote client for Superserver on posix is libfbclient.so. The see-saw
goes the other way on posix - a client can't connect locally to a database
- it has to use the remote client and the local loopback server. You also
use libfbclient.so for remote clients to Classic.
You think it's confusing now....in IB and in Fb 1, both the local client
and the remote client have the *same* name. :-)
to avoid the "see-saw" effect, where, at the load threshold, Windows shifts
the entire load from one processor to another. All other configurations
work with SMP but there is no threading optimisation to *take advantage* of
SMP.
"cooked" network protocol where the "wire" is the inter-process
communication space that is shared by the client and the server. For Fb 2,
the IPServer is being reimplemented to use the virtual local network
subsystem, XNET.
But wait and see whether Nando Dessena comes back on this one, as he does
things with Win Embedded that aren't supposed to be possible...
./helen
>On Monday 30 August 2004 11:22, Steffen Heil wrote:It does *seem* so but it's not so. The Windows Embedded Server model is a
>
> > Embedded is SS only [for single connections].
> >
> > Also, afaik, embedded is still not supported under OSes other than windows.
>
>I have seen references to FB embedded on Linux on this list, and indeed the
>FirebirdSS rpm comes with "libfbembedd.x.so". I will check to ensure that
>that file is what I think it is, but it does *seem* to be supported on Linux.
Superserver and a client rolled into a single library.
On POSIX, you have the ability to connect an application directly to an
instance of the Classic server. (the xinet daemon listens for connections
and flashes up an instance of the server for each client connection). For
this direct connection, you use the client that is named libfbembed.so. So
it's more akin (logically) to the IPServer connection on Windows which,
confusingly, is not available for Classic clients on Windows.
The most likely use of this libfbembed client is for creating server-based
apps using Embedded SQL - hence the word "embed" in its name. Yeah, I had
one of my many famous arguments with N. Samofatov about this renaming. It
works fine for local client apps not written in ESQL, too. I've got apps
using it that were written in Kylix, though never load-tested. Kylix
server apps are NOT light in weight!!
The remote client for Superserver on posix is libfbclient.so. The see-saw
goes the other way on posix - a client can't connect locally to a database
- it has to use the remote client and the local loopback server. You also
use libfbclient.so for remote clients to Classic.
You think it's confusing now....in IB and in Fb 1, both the local client
and the remote client have the *same* name. :-)
>The docs say that FB SS does not support SMP/HT. Does this mean I cannot runOn Windows SS, no, you have to keep the CPU Affinity set to one processor
>it on an SMP system, or that I can, but it will just not take advantage of
>the multiple processors? In other words, does anyone run Firebird SS on an
>SMP box??
to avoid the "see-saw" effect, where, at the load threshold, Windows shifts
the entire load from one processor to another. All other configurations
work with SMP but there is no threading optimisation to *take advantage* of
SMP.
>And lastly, about thread-safety: I don't expect 'FB-embedded SS' to beTheoretically, it's not possible, since it uses the IPServer, a kind of
>thread-safe out of the box, but is it at least thread-friendly? I can find
>out the answer to this with a lot of testing, but I want to know if anyone is
>running FB-embedded in a multi-threaded app.
"cooked" network protocol where the "wire" is the inter-process
communication space that is shared by the client and the server. For Fb 2,
the IPServer is being reimplemented to use the virtual local network
subsystem, XNET.
But wait and see whether Nando Dessena comes back on this one, as he does
things with Win Embedded that aren't supposed to be possible...
./helen
>Regards,
>
>Bud Millwood
>Weird Solutions, Inc.
>http://www.weird-solutions.com
>tel: +46 8 758 3700
>fax: +46 8 758 3687
>mailto:budm@...
>
>
>
>
>Yahoo! Groups Links
>
>
>
>