[VXI11] Create_LinkResp structure (without RPCGEN)

[abk]

Hello,
I am trying to analyse the client - server communication between the Visa Interactive Control and the Agilent Remote Server. Since it should be comprehensible with basic knowledge of RPCs and the VXI-11 protocol (VXIbus), I am encountering some difficulties.
(Upper half of the table below)
The green shaded Bytes in the call (client to server) are RPC specific information:
(44 bytes, in 4 byte tuples)
FragmentInfo - XID - MessageType - RPCVers - Prog - Vers - Proc - Cred.Flavor - Cred. Length - Verf.Flavor - Verf.Length
The following 20 bytes (turquoise shaded, 4 byte tuples) are VXI-11 specific:

struct Create_LinkParms {
    long clientId; /* implementation specific value.*/
    bool lockDevice; /* attempt to lock the device */
    unsigned long lock_timeout; /* time to wait on a lock */
    string device<>; /* name of device */
};

Note that „device<>“ is 4 byte for „length“ followed by the string in 4byte tuples, filled with zeros. In this certain case 4 bytes „length“ and 4 bytes for the string itself.

The reply (server to client) seems pretty clear, too: Green shaded RPC, followed by grey shaded VXI11 specific reply (16 Bytes, 4byte tuples):

struct Create_LinkResp {
    Device_ErrorCode error;
    Device_Link lid;
    unsigned short abortPort; /* for the abort RPC */
    unsigned long maxRecvSize; /* specifies max data size in bytes
                                device will accept on a write */
};

Everything seems to be fine, but there is no attempt of the VISA Interactive IO to connect to the abort port. (The assigned port is accessible, e.g. via telnet!)
Then I have tried to connect to Agilent Remote Server with Agilent Interactive IO.(Lower half of table below)
Call (Client to server): Green shaded bytes are RPC specific value, turqouise shaded bytes differ from the VXI-11 create_LinkParms call:
The last bytes (4 tuples) are the string and the 4 bytes ahead are the length. But what are these 4 zero bytes?? what happend to clientID, lockDevice and lock_timeout? I assumed that lockDevice and lock_timeout are not present if the clientID is 0x00000000.
The reply (server to client) is strange as well:
Green shaded bytes = RPC, thats ok. Now there are 36 Bytes insted of 16!
The grey shaded bytes are the bytes I've expected, even in the right order:
0x00000000 for error code(=OK), 0x003afb68 link ID (seems ok),the abort port 0x00000440 and the maxRecvSize 0xffffffff. This message is accepted as well, the Agilent Interactive IO even connects to the abort port.
But I can't identify the magenta bytes in between and don't know where they come from. Are there any information about generating VXI-11 replys aside from the VXI-11 Protocol by VXIbus? Note that I can not use the rpcgen because my system does not support the required libaries. I am looking forward to any help I can get!

Message Edited by abk on 04-15-2008 06:29 AM

[Makoto]

In the stream hex-dump you provided, there are two Program# values exist -- 0x000607AF (NI VISA interactive) and 0x000607AC (Agilent IO).  The former is the VXI-11 Core Channel program# that is exactly documented in the VXI-11 spec, but the later is not documented anywhere.  Probably it looks like pre-VXI-11 spec of something like that, which is often used by Agilent IO library as the 1st try of create_link prior to the documented official VXI-11.

Agilent IO library looks like use 1st try approach using program# 0x000607AC to connect the VXI-11/LXI instrument, and if it failed, goes to 2nd try using program# 0x000607AF.  As I know, most of Agilents' instruments will respond to the 1st try without error, therefore Agilent IO library can continue to use this port and protocol. But most of other vendor's instrument will not.  Then Agilent IO library's 2nd try will connect the instrument then.  As for NI-VISA, it only uses official VXI-11 Core Channel program#.

Unfortunately I don't have any info about RPC program# 0x000607AC, therefore  I can't tell anything about the magenta colour part of your hex-dump.  But the Agilent's 1st try way looks like not to contain device lock timeout info. 

As for Abort port, the VXI-11 spec says an instrument shall have the abort port, which will be informed to the client PC through the create_link response (rather than port mapper's GET_PORT function).  But current VISA implementation seems like not using this port. 

このメッセージは　04-16-2008 10:22 AMに Makoto が編集しています。

[abk]

Thank you for the answer! I noticed the difference in the program# and the attempt to reconnect, too. But I've not traced it any further because I assumed that this is the result of not getting an Abort Channel. I'm going to examine this more closely and post my results here.