Menu
▾
▴
firebird-devel
|
From: Nando D. <na...@de...> - 2003-06-30 18:20:15
|
Hello, I know this is pretty much a strange setup, but I would be able to solve many problems I have if I could count on this couple (Fbembed as an embedded server and as a client for a local or remote IB server v5.6) to work reliably. So, can any of the developers say why it wouldn't work, or suggest areas to test more than others, or anyway comment on this one? Of course I plan to use dialect 1 exclusively, for now. Thanks -- Nando mailto:na...@de... |
|
From: Mike N. <ta...@al...> - 2003-06-30 20:15:17
|
Nando Dessena asked: > I know this is pretty much a strange setup, but I would be able to solve many > problems I have if I could count on this couple (Fbembed as an > embedded server and as a client for a local or remote IB server v5.6) to > work reliably. So, can any of the developers say why it wouldn't > work, You have two DLL's with the same exported names. Somehow you have to tell your runtime what connection you want to use, in-process server or remote. Or are you (seriously, as can be read from your post) suggesting that the local-only (embedded) server should act as mediator for remote connections also? Perhaps what you need is an extra layer (your work) between Firebird and the connection method, so your app can select local server or remote at will? To put remote access in the local server not only creates security holes the size of Windows 9x run by idiots clicking on any and every attachment they get, it also muddies the waters of where what borders are. Local in-process server, aka "fbembed" is AFAIK what it tells you to be. If someone added remote capabilities to that DLL, all of a sudden it would have just those remote access capabilities - i.e. it would be a security problem. > or suggest areas to test more than others, or anyway comment on > this one? I suggest you do it like e.g. IBPP, dynamically load the DLL(s) and GetProcAddress for the entry points. Else you wouldn't know what enrty point went to server/client and ... Well, I think you can imagine the resulting SEGV's would get messy. :-) > Of course I plan to use dialect 1 exclusively, for now. How would that be obvious? Personally I use nothing but dialect 3, and I don't see a reason to hang on to anything older unless forced to. /Mike |
|
From: Artur A. <ar...@ar...> - 2003-06-30 22:30:47
|
Hi Mike, > Or are you (seriously, as can be read from your post) suggesting that the > local-only (embedded) server should act as mediator for remote connections > also? Not only him, but lots of people. This was discussed here, and here it is what I remember: a) This feature will be great for people using off-line systems. They will be abble to use the embedded version to connect to the local database, and this feature to connect at the end of the day to a central database. This will make live easy. The embedded server should act as a server for local connections, and as a client for any other type of connection. b) Dmitry had the embedded server working just like this in the past, but this was removed because we decided here to remove it. At the time, none of us was abble to recognize the beneficts of this feature. My resume of the story will finish here. I can not remember what was the finnal decision, since the embedded server is not a priority of the project. Artur |
|
From: Mike N. <ta...@al...> - 2003-07-01 10:21:13
|
Artur Anjos wrote: > > Or are you (seriously, as can be read from your post) suggesting that the > > local-only (embedded) server should act as mediator for remote > > connections also? > > Not only him, but lots of people. OK, fair enough. I'm sorry if I stepped on some toes here. I don't see anything stopping a version of the embedded server allowing it to act as remote client also, but I think that should be a variant of its own. IMHO the default embedded shouldn't even have any socket calls left compiled in, much less this capability. /Mike |
|
From: Dmitry Y. <di...@us...> - 2003-07-01 10:37:50
|
Mike, > I don't see anything stopping a version of the embedded > server allowing it > to act as remote client also, but I think that should be a > variant of its own. Oh, my god. Do you suggest introducing new binaries? fbserver.exe + fb_inet_server.exe + fbembed.dll + fbembed_with_remote_client.dll? Isn't it too complex to maintain and support? To be honest, the above issues are very selfish. But since I'm the only one who works on the embedded server, I prefer to assign my worries the highest priority. Dmitry |
|
From: Mike N. <ta...@al...> - 2003-07-01 11:55:57
|
Dmitry Yemanov wrote: > Oh, my god. Do you suggest introducing new binaries? fbserver.exe + > fb_inet_server.exe + fbembed.dll + fbembed_with_remote_client.dll? I raised that as an option, yes. I'd prefer that fbembed stays in its little local-machine, and local-machine *only*, sandbox, unless explicitly given permission to roam the net by either the "fbembed_with_remote_client.dll" approach, or ... (more below) > Isn't it too complex to maintain and support? "Just one more macro conditional..." *ducks* Im kidding, I'm kidding! :-) > To be honest, the above issues are very selfish. But since I'm the only one > who works on the embedded server, I prefer to assign my worries the highest > priority. I understand you concerns, and I sure don't want to add more burden. Maybe the idea I had about the y-valve compiled into fbembed could load fbclient.dll (if present) and get its remote functionality from that one? Wouldn't that satisfy both the security (and possibly privacy) concerns I raised, while not adding any extra maintenance work? It would also keep down the size, and dependencies, of fbembed for running it by itself in scenarios where remote access is unwanted or unneeded. /Mike |
|
From: Marv C. <mj...@in...> - 2003-07-05 17:34:06
|
Hi all, I installed the embedded server in its own directory, copied IB Expert into that directory and successfully created a database. I then tried to access that database using IBO. No joy. ISC ERROR CODE:335544375 ISC ERROR MESSAGE: unavailable database I have tried all kinds of connections strings with no success. Any hints? Thanks, Marv |
|
From: Dmitry Y. <di...@us...> - 2003-07-06 04:43:41
|
Marv, > I installed the embedded server in its own directory, copied > IB Expert into > that directory and successfully created a database. I then > tried to access that database using IBO. No joy. > > ISC ERROR CODE:335544375 > > ISC ERROR MESSAGE: > unavailable database Do you have the embedded server in your app directory? Dmitry |
|
From: Marv C. <mj...@in...> - 2003-07-06 13:26:45
|
>>Do you have the embedded server in your app directory? Dmitry, I found the problem. I had a copy of GDS32.DLL in my system32 directory. When that was removed, everything works as planned. Thanks for you help (and for the fine product) Marv |
|
From: Tony C. <ac...@am...> - 2003-07-06 14:45:21
|
> I found the problem. I had a copy of GDS32.DLL in my system32 directory. > When that was removed, everything works as planned. See the howto I wrote here: http://groups.yahoo.com/group/IBObjects/message/25798 You should not have to remove gds32.dll from you system dir, and the howto will show you how. The key is to tell IBO to use a different name for the client lib. Tony Caduto |
|
From: Tony C. <ac...@am...> - 2003-07-06 14:42:43
|
Go to the IBO groups at yahoogroups.com and do a search on fbembeded HOWTO. here is a direct link: http://groups.yahoo.com/group/IBObjects/message/25798 I wrote it a couple of weeks ago and should really help you out |
|
From: Nando D. <na...@de...> - 2003-07-01 06:29:45
|
Mike, thanks for replying. M> You have two DLL's with the same exported names. Somehow you have to tell M> your runtime what connection you want to use, in-process server or remote. M> Or are you (seriously, as can be read from your post) suggesting that the M> local-only (embedded) server should act as mediator for remote connections M> also? Actually, I was taking that for granted. :-) I'm not sure what additional security problems I would have since I already have an IB client installed. I'm not suggesting that it should listen to incoming connections, just that it acts as a pure client when told to do so. M> Perhaps what you need is an extra layer (your work) between Firebird and the M> connection method, so your app can select local server or remote at will? This is alternative 2 in my list. I am using Delphi+IBO (which already does dynamic loading of the client DLL) and I think it wouldn't be too difficult to select a different set of pointers on a per session basis (provided I convice the author that it makes sense, of course!). Alternative 1 looks better to me, though. M> To put remote access in the local server not only creates security holes the M> size of Windows 9x run by idiots clicking on any and every attachment they M> get, it also muddies the waters of where what borders are. Can you elaborate on the first point? As for the second, I don't see it as architecturally dumb as you. To me it looks slick, in fact. I'd dare to propose that fbembed should be able to be used as a client even for a local server (that is, connecting to databases through the local protocol), e.g. a way should be found to specify in the connection string whethere it's an "embedded" connection or one to be forwarded. I think now it considers all local connections embedded. >> Of course I plan to use dialect 1 exclusively, for now. M> How would that be obvious? Personally I use nothing but dialect 3, and I M> don't see a reason to hang on to anything older unless forced to. I am. See the subject line. Ciao -- Nando mailto:na...@de... |
|
From: Frank Schlottmann-G. <fs...@us...> - 2003-07-01 06:50:33
|
Mike Nordell wrote:
> Nando Dessena asked:
>
>
>>I know this is pretty much a strange setup, but I would be able to solve
>
> many
>
>>problems I have if I could count on this couple (Fbembed as an
>>embedded server and as a client for a local or remote IB server v5.6) to
>>work reliably. So, can any of the developers say why it wouldn't
>>work,
>
>
> You have two DLL's with the same exported names. Somehow you have to tell
> your runtime what connection you want to use, in-process server or remote.
> Or are you (seriously, as can be read from your post) suggesting that the
> local-only (embedded) server should act as mediator for remote connections
> also?
It's only one dll in this scenario.
I'm using the embedded server for notebook-installations in this way.
It acts as a server for a local copy of a part of the main database if
it is not connected to the local network.
Otherwise it acts as a client to the main server.
I don't know whether this will work against a 5.6 server though.
Frank
--
"Fascinating creatures, phoenixes, they can carry immensely heavy loads,
their tears have healing powers and they make highly faithful pets."
- J.K. Rowling
|
|
From: Dmitry Y. <di...@us...> - 2003-07-01 07:54:40
|
Mike, > Or are you (seriously, as can be read from your post) > suggesting that the > local-only (embedded) server should act as mediator for > remote connections also? That's how people want the embedded server to work. The current builds allow fbembed.dll to be a client for remote servers. > Local in-process server, aka "fbembed" is AFAIK what it tells > you to be. If > someone added remote capabilities to that DLL, all of a > sudden it would have > just those remote access capabilities - i.e. it would be a > security problem. The embedded server is a big security problem by just the fact of its existence, because the application has full access to the internal engine structures, page cache, etc. Dmitry |
|
From: Nando D. <na...@de...> - 2003-07-01 08:56:07
|
Dmitry, DY> The current builds allow fbembed.dll to be a client for remote servers. what about allowing it to forward even local connections to a server located in the same machine? Does it make sense? I am thinking about existing installations that use local connection, into which I must inject fbembed, so that I would have one embedded connection to fbembed and one local connection to IBServer. I could change the latter to a local TCP connection, but what if the (old) machine doesn't have TCP? Ciao -- Nando mailto:na...@de... |
|
From: Dmitry Y. <di...@us...> - 2003-07-01 10:31:11
|
Nando, > DY> The current builds allow fbembed.dll to be a client for > remote servers. > > what about allowing it to forward even local connections to a server > located in the same machine? Does it make sense? No, I don't think so. > I am thinking about existing installations that use local connection, > into which I must inject fbembed, so that I would have one embedded > connection to fbembed and one local connection to IBServer. > I could change the latter to a local TCP connection, but what if the > (old) machine doesn't have TCP? I thought that FB cannot run on machines without TCP stack installed. Even backup/restore code uses winsock routines. Dmitry |
|
From: Nando D. <na...@de...> - 2003-07-01 10:54:59
|
Dmitry, >> I am thinking about existing installations that use local connection, >> into which I must inject fbembed, so that I would have one embedded >> connection to fbembed and one local connection to IBServer. >> I could change the latter to a local TCP connection, but what if the >> (old) machine doesn't have TCP? DY> I thought that FB cannot run on machines without TCP stack installed. Even DY> backup/restore code uses winsock routines. IB5.6 does. That was my primary concern. Ciao -- Nando mailto:na...@de... |
|
From: Helen B. <he...@tp...> - 2003-07-01 08:55:41
|
At 11:54 AM 1/07/2003 +0400, Dmitry Yemanov wrote: >Mike, > > > Or are you (seriously, as can be read from your post) > > suggesting that the > > local-only (embedded) server should act as mediator for > > remote connections also? > >That's how people want the embedded server to work. The current builds allow >fbembed.dll to be a client for remote servers. I haven't tested it myself, but that's actually contrary to what the doc says. Doc says it doesn't support any remote access protocol, including local loopback. Is anything else there not up to date? > > Local in-process server, aka "fbembed" is AFAIK what it tells > > you to be. If > > someone added remote capabilities to that DLL, all of a > > sudden it would have > > just those remote access capabilities - i.e. it would be a > > security problem. > >The embedded server is a big security problem by just the fact of its >existence, because the application has full access to the internal engine >structures, page cache, etc. I wonder whether Nando noticed that he didn't need to log in to get server access... Helen |
|
From: Frank Schlottmann-G. <fs...@us...> - 2003-07-01 09:15:34
|
Helen Borrie wrote:
> At 11:54 AM 1/07/2003 +0400, Dmitry Yemanov wrote:
>
>> Mike,
>>
>> > Or are you (seriously, as can be read from your post)
>> > suggesting that the
>> > local-only (embedded) server should act as mediator for
>> > remote connections also?
>>
>> That's how people want the embedded server to work. The current builds
>> allow
>> fbembed.dll to be a client for remote servers.
>
>
> I haven't tested it myself, but that's actually contrary to what the doc
> says. Doc says it doesn't support any remote access protocol, including
> local loopback. Is anything else there not up to date?
There was no release of an embedded server that is working this way, so
the documentation is still valid for the RC1 version.
The unofficial snapshot build is both working as a client and as a local
server.
Frank
--
"Fascinating creatures, phoenixes, they can carry immensely heavy loads,
their tears have healing powers and they make highly faithful pets."
- J.K. Rowling
|
|
From: Helen B. <he...@tp...> - 2003-07-01 09:32:28
|
At 11:21 AM 1/07/2003 +0200, Frank Schlottmann-Goedde wrote: >>>That's how people want the embedded server to work. The current builds allow >>>fbembed.dll to be a client for remote servers. >> >>I haven't tested it myself, but that's actually contrary to what the doc >>says. Doc says it doesn't support any remote access protocol, including >>local loopback. Is anything else there not up to date? > >There was no release of an embedded server that is working this way, so >the documentation is still valid for the RC1 version. > >The unofficial snapshot build is both working as a client and as a local >server. Frank, sorry, I can't make sense of this. Is the short answer --- "The doc was correct for RC 1 but it's no longer correct for RC 3?" Another thing I can't make sense of is that it was announced that fbembed.dll was in the RC 3 kit. It's not. So where is this RC 3 fbembed that all you people are playing with? rgds, Helen |
|
From: Frank Schlottmann-G. <fs...@us...> - 2003-07-01 10:35:34
|
Helen Borrie wrote: > At 11:21 AM 1/07/2003 +0200, Frank Schlottmann-Goedde wrote: > >>>> That's how people want the embedded server to work. The current >>>> builds allow >>>> fbembed.dll to be a client for remote servers. >>> >>> >>> I haven't tested it myself, but that's actually contrary to what the >>> doc says. Doc says it doesn't support any remote access protocol, >>> including local loopback. Is anything else there not up to date? >> >> >> There was no release of an embedded server that is working this way, >> so the documentation is still valid for the RC1 version. >> >> The unofficial snapshot build is both working as a client and as a >> local server. > > > Frank, sorry, I can't make sense of this. Is the short answer --- > > "The doc was correct for RC 1 but it's no longer correct for RC 3?" There is no RC3 embedded server that I know of. The only version that exists is my snapshot build in http://firebird.sourceforge.net/download/snapshot_builds/fb15embed/ Frank -- "Fascinating creatures, phoenixes, they can carry immensely heavy loads, their tears have healing powers and they make highly faithful pets." - J.K. Rowling |
|
From: Artur A. <ar...@ar...> - 2003-07-01 09:47:54
|
> Another thing I can't make sense of is that it was announced that > fbembed.dll was in the RC 3 kit. It's not. So where is this RC 3 fbembed > that all you people are playing with? It's a snapshot available by IBPhoenix web site. Artur |
|
From: Helen B. <he...@tp...> - 2003-07-01 09:54:28
|
At 10:46 AM 1/07/2003 +0100, Artur Anjos wrote: > > Another thing I can't make sense of is that it was announced that > > fbembed.dll was in the RC 3 kit. It's not. So where is this RC 3 fbembed > > that all you people are playing with? > >It's a snapshot available by IBPhoenix web site. Thks Artur. cheers, Helen |
|
From: Dmitry Y. <di...@us...> - 2003-07-01 07:50:40
|
Nando, > I know this is pretty much a strange setup, but I would be > able to solve many > problems I have if I could count on this couple (Fbembed as an > embedded server and as a client for a local or remote IB > server v5.6) to > work reliably. So, can any of the developers say why it wouldn't > work, or suggest areas to test more than others, or anyway comment on > this one? It should work fine, IMO. Dmitry |
|
From: Nando D. <na...@de...> - 2003-07-01 08:57:02
|
Dmitry, >> I know this is pretty much a strange setup, but I would be >> able to solve many >> problems I have if I could count on this couple (Fbembed as an >> embedded server and as a client for a local or remote IB >> server v5.6) to >> work reliably. So, can any of the developers say why it wouldn't >> work, or suggest areas to test more than others, or anyway comment on >> this one? DY> It should work fine, IMO. Thanks; I will experiment and possibly post the results here in case anyone else is interested. Ciao -- Nando mailto:na...@de... |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X