VMCI and vsocklib.dll

[Jeff3]

Can someone point me in the right direction with vsocklib.dll?

Do I understand correctly that I can just include the vmci_sockets.h file and adjust my socket calls to use the new af/addr structures? If so, how does vsocklib.dll fit into the picture? Does it encapsulate/export any of the socket functionality?

The programming guide shows windows apps talking to the vmci driver throught the vsocklib.dll, but I guess I'm not understanding what is being called in that library.

Thanks for your help.

Jeff

[Jeff3]

Okay, I see vsocklib.dll only exports WSPStartup, which I assume tells the winsock stack about vmci. Then I'm off and running with the ws2_32.dll functions, right?

Thanks again.

Jeff

[Jeff3]

Sorry for the monologue here...

I understand now that the vsocklib.dll is the winsock service provider dll. And so, like the documentation says, I can just interact normally with ws2_32.dll because the vmci address family is mapped to that library.

I am now trying to figure out how to distribute the server's CID to multiple clients. Anybody know if I can use VMCI DGRAM to broadcast the server's CID out to any client's listening? Otherwise, it looks like I can set a static CID when I create the vm through the VimApi.

Thanks.

[admin]

Glad you figured out the other questions.

>I am now trying to figure out how to distribute the server's CID to multiple clients. Anybody know if I can use VMCI DGRAM to broadcast the server's CID

>out to any client's listening? Otherwise, it looks like I can set a static CID when I create the vm through the VimApi.

I assume you are working on ESX from the above.

The vim api exposes the VMCI context id of a vm in versions >= ESX 4.1 but does not allow you to change it. There is no broadcast mode for VMCI datagrams.

If you don't mind manually editing the vmx files of your vm (not supported) you can always set vmci0.id = or query the VIM api.

The only time your VMCI id will change currently is if you vmotion it or power it on and there is another VM on the system already running with the context id specified in the vmx file.

You can add vmci0.idPolicy = "fail" in the server vm vmx file if you don't want your server vm to power on if it cannot get the context id specified in the vmx file of the vm.

If the above doesn't work for you please provide a little bit more detail about your setup and I'll see if I can suggest something else.