Direct IP access in OpenAPI

[zhenchen17]

Hi all,
Is it possible to access a database directly with IP address , instance name and protocol? For example, In the normal way, i want to visit the database in 192.168.1.1 / II / TCP/IP, a virtual node with the provided information should be created. Then, when connecting to database, virtual node and database name are both should be provided.
But i wonder if there is another way to access it directly with a certain connecting string something like **192.168.1.1;ii;tcp/ip;iidbdb**. I can't find any information in OpenAPI user guide and IIapi_connect call seems no parameters for it. But I saw the similar string in Dot Net Provider.

Thanks for any comments.
Wishes!

Chen zhen

[pickr01]

Use a "dynamic vnode". This works with OpenAPI and with every other api/tool using Ingres/NET.
Specify the dbname as follows:
"@192.168.1.1,tcp_ip,ii[username,password]::iidbdb"

If I remember right, the password must not contain a space or comma.

DotNET (and JDBC) is different, you don't use Ingres/NET to connect to the DAS server.
(even though the database name itself can contain a vnode and so a dynamic vnode too, so the DAS server connects via Ingres/NET to the database)

Kristoff

[nick.bolton]

Dynamic vnodes are documented here. Came in with Ingres r3 (aka 9.0, 2006 etc.) IIRC:

http://docs.ingres.com/Ingres/9.2/Co...gnet.htm#o1212

[zhenchen17]

Originally Posted by pickr01

Use a "dynamic vnode". This works with OpenAPI and with every other api/tool using Ingres/NET.
Specify the dbname as follows:
"@192.168.1.1,tcp_ip,ii[username,password]::iidbdb"

If I remember right, the password must not contain a space or comma.

DotNET (and JDBC) is different, you don't use Ingres/NET to connect to the DAS server.
(even though the database name itself can contain a vnode and so a dynamic vnode too, so the DAS server connects via Ingres/NET to the database)

Kristoff

It works!
Thanks Kristoff.

By the way, is instance case sensitive? ii equals II or Ii or iI?


Chen zhen

[nick.bolton]

The instance ID is not meant to be case sensitive.

There's an article about them here, which gives some detail on how they work:
Ingres TCP Ports - Ingres Community Wiki

Personally, I don't find that explanation of how that maps to a port number very clear.

The way I understand it works is:
- Take character 1, turn it into uppercase, get the ASCII value
- Perform a logical AND against the ASCII value and 31
- Multiply this value by 512

- Take character two, turn it into uppercase, get the ASCII value
- Perform a logical AND against the ASCII value and 63
- Multiply this value by 8

- Add the two numbers together, and then add on 16384
- If there is a trailing digit 0 to 7 on the port name (i.e. multiple net servers), add that on as well.

So, for installation II, we get
I = ASCII 73
73 AND 31 = 9
9 x 512 = 4608

I = ASCII 73
73 AND 63 = 9
9 x 8 = 72

Add these together with 16384 = port 21064


One interesting thing to note, is that there is no reason why the port ID for a set of communication servers has to be the same as that of the Ingres installation. This allows you some options on which network ports you want a comms server to run against.

[pickr01]

It is case insensitive - when computing the listen address.

Kristoff

[zhenchen17]

Originally Posted by nick.bolton@barclays.com

Dynamic vnodes are documented here. Came in with Ingres r3 (aka 9.0, 2006 etc.) IIRC:

http://docs.ingres.com/Ingres/9.2/Co...gnet.htm#o1212

Thanks nick.

In the documentation, a dynamic virtual node are described as follow:

A dynamic vnode specification has the following format:

@host,protocol,port[;attribute=value{;attribute=value}][[user,password]]

...

Note: The user and password are optional for a dynamic vnode, but must be enclosed in brackets if used.

if i don't want to pass user and password, what should it be like?

I tried @192.168.1.1,tcp_ip,ii
@192.168.1.1,tcp_ip,ii[]
@192.168.1.1,tcp_ip,ii[,]
but all failed.

Thanks
regards

chen zhen

[zhenchen17]

Originally Posted by nick.bolton@barclays.com

The instance ID is not meant to be case sensitive.

There's an article about them here, which gives some detail on how they work:
Ingres TCP Ports - Ingres Community Wiki

Personally, I don't find that explanation of how that maps to a port number very clear.

The way I understand it works is:
- Take character 1, turn it into uppercase, get the ASCII value
- Perform a logical AND against the ASCII value and 31
- Multiply this value by 512

- Take character two, turn it into uppercase, get the ASCII value
- Perform a logical AND against the ASCII value and 63
- Multiply this value by 8

- Add the two numbers together, and then add on 16384
- If there is a trailing digit 0 to 7 on the port name (i.e. multiple net servers), add that on as well.

So, for installation II, we get
I = ASCII 73
73 AND 31 = 9
9 x 512 = 4608

I = ASCII 73
73 AND 63 = 9
9 x 8 = 72

Add these together with 16384 = port 21064


One interesting thing to note, is that there is no reason why the port ID for a set of communication servers has to be the same as that of the Ingres installation. This allows you some options on which network ports you want a comms server to run against.

That is interesting.

But in some application, when connect to server, only IP address and port are asked. So if the port id is know, is there any way to compute what is the instance ID?

The easies way is to make a map, II ----- 21064
IJ ----- ****
IK ----- ****
but it seems stupid...

Thanks

chenzhen

[clach04]

The linked wiki article contains code for doing reverse looks ups already. Call with the "-r" flag

RE case sensitivity of the installation id/code. Whilst the installation id is case insensitive it makes sense to be consistent with the case when dealing with it. For example the character set for an installation is stored in the symbol table in a vairable called II_CHARSETxx where xx is the installation id. The symbol table is case sensitive:

C:\>ingprenv II_CHARSETR2
WIN1252

C:\>ingprenv II_CHARSETr2

C:\>

%ingprenv II_CHARSETGW
ISO88591
%ingprenv II_CHARSETgw
%

I.e. only treat it as case insensitive when using it in a network (address) context. Treat as case sensitive in all other cases.