Re: SE on Linux

"Art S. Kagel" wrote: > > > > Still it is not clear to me what you mean by "IP style connection" made > > through the pipe or named pipe. IP has nothing to do with all this. > > No it does not. But Informix is coding using network style code, This sounded a plausible theory, but I think it's not right. I'm getting curious about this issue and I'm running "lsof" (list open files) on my informix process to see what files it is opening. I get : sqlexec 11922 root 0r FIFO 0,0 11908 pipe sqlexec 11922 root 1w FIFO 0,0 11907 pipe sqlexec 11922 root 2u CHR 4,64 128388 /dev/ttyS0 sqlexec 11922 root 3r REG 8,1 66062 228820 /usr/informix/msg/en_us/0333/sql.iem note the FIFO fields. In the case of Postgres configured to use unix domain sockets, I get: postmaster 94 postgres 3u unix 0xdf417980 142 /tmp/.s.PGSQL.5432 using the same lsof utility. So I think Informix is using GENUINE pipes and not the sockaddr_un interface. Either way, I think it's not necessary for this to have the hostname or tcp port number.

David Stes wrote: > > "Art S. Kagel" wrote: > > > > > > Still it is not clear to me what you mean by "IP style connection" made > > > through the pipe or named pipe. IP has nothing to do with all this. > > > > No it does not. But Informix is coding using network style code, > > This sounded a plausible theory, but I think it's not right. > > I'm getting curious about this issue and I'm running "lsof" (list open > files) on my informix process to see what files it is opening. > > I get : > > sqlexec 11922 root 0r FIFO 0,0 11908 pipe > sqlexec 11922 root 1w FIFO 0,0 11907 pipe > sqlexec 11922 root 2u CHR 4,64 128388 /dev/ttyS0 > sqlexec 11922 root 3r REG 8,1 66062 228820 > /usr/informix/msg/en_us/0333/sql.iem > > note the FIFO fields. > > In the case of Postgres configured to use unix domain sockets, I get: > > postmaster 94 postgres 3u unix 0xdf417980 142 > /tmp/.s.PGSQL.5432 > > using the same lsof utility. > > So I think Informix is using GENUINE pipes and not the sockaddr_un > interface. Interesting, it sure looks that way. > Either way, I think it's not necessary for this to have the hostname or > tcp port number. Hmmm. Excuse me I have to go some sticky yellow stuff off my face... Art S. Kagel

"Art S. Kagel" wrote: > David Stes wrote: > > "Art S. Kagel" wrote: > > > > Still it is not clear to me what you mean by "IP style connection" made > > > > through the pipe or named pipe. IP has nothing to do with all this. > > > > > > No it does not. But Informix is coding using network style code, > > > > This sounded a plausible theory, but I think it's not right. > > > > I'm getting curious about this issue and I'm running "lsof" (list open > > files) on my informix process to see what files it is opening. > > I get : > > > > sqlexec 11922 root 0r FIFO 0,0 11908 pipe > > sqlexec 11922 root 1w FIFO 0,0 11907 pipe > > sqlexec 11922 root 2u CHR 4,64 128388 /dev/ttyS0 > > sqlexec 11922 root 3r REG 8,1 66062 228820 > > /usr/informix/msg/en_us/0333/sql.iem > > > > note the FIFO fields. > > > > In the case of Postgres configured to use unix domain sockets, I get: > > > > postmaster 94 postgres 3u unix 0xdf417980 142 > > /tmp/.s.PGSQL.5432 > > > > using the same lsof utility. > > > > So I think Informix is using GENUINE pipes and not the sockaddr_un > > interface. > > Interesting, it sure looks that way. That's what I'd expect. > > Either way, I think it's not necessary for this to have the hostname or > > tcp port number. > > Hmmm. Excuse me I have to go some sticky yellow stuff off my face... I believe the sqlhosts file on a machine host1 could have entries such as: se_1 seipcpip host1 sqlexec se_2 seipcpip host2 sqlexec If you set INFORMIXSERVER to se_2, host1 has to determine what its own name is, and compare that with the entry for se_2 and then refuse to connect on the grounds that it is not the specified host (and the protocol would be setlitcp or sesoctcp if a network connection was intended). So, the name lookup code does need to be able to resolve the host name in the sqlhosts file into its own name -- even though it may never touch a networking routine again. -- Jonathan Leffler (jleffler@informix.com, jleffler@earthlink.net) Guardian of DBD::Informix v1.00.PC1 -- see http://www.perl.com/CPAN #include <disclaimer.h>

Jonathan Leffler wrote: > > I believe the sqlhosts file on a machine host1 could have entries such as: > > se_1 seipcpip host1 sqlexec > se_2 seipcpip host2 sqlexec > > If you set INFORMIXSERVER to se_2, host1 has to determine what its > own name is, and compare that with the entry for se_2 and then refuse to > connect on the grounds that it is not the specified host (and the protocol > would be setlitcp or sesoctcp if a network connection was intended). However, perhaps ironically, such an attempt to "protect" the user from mistakes in the sqlhosts configuration file may give more problems than it actually solves. Host resolving issues can sometimes be complicated ... Suppose you have a small site where they run Informix using local IPC, and they install an internet connection package, and get an ip address by bringing up a PPP link or so : boom! Informix would perhaps not start any longer because the hostname happens to be different at once than the one specified in the sqlhosts file. I'd rather have informix just do _no_ host lookup _at all_ in the case of seipcpip. > So, the name lookup code does need to be able to resolve the host name in > the sqlhosts file into its own name -- even though it may never touch a > networking routine again. If it doesn't need a networking routine, it should not call such a routine, not even once. One time is enough to give problems...