“Contact strings” and browsing for Xgrids

The DRMAA specification includes the possibility of having the API return a list of “contacts”—identifiers for different grids. This seemed like a pretty natural place to return a list of controllers/grids discovered via Bonjour, so I went ahead and implemented the service browsing on a separate thread, managing it correctly with NSRunLoop, etc., and, when I was done, realized that authentication would not work at all in the context of DRMAA unless no authentication was required. So I commented all that code out—I’ll bring back snippets of the run-loop management back for the actual XgridFoundation code.

Instead, I have returned fully to the idea of just using the defaults database and a preference pane to store all this data. I’ve added string constants for all the data that will be needed to store a selected grid to XgridDRMAATypesAndConstants.h:

extern NSString *XgridDRMAAIdentificationMethod;
extern NSString *XgridDRMAANetServiceIdentificationMethod;
extern NSString *XgridDRMAAHostnameIdentificationMethod;

extern NSString *XgridDRMAANetServiceDomain;
extern NSString *XgridDRMAANetServiceName;

extern NSString *XgridDRMAAHostnameOrIP;
extern NSString *XgridDRMAAPortNumber;

extern NSString *XgridDRMAAGridName;

extern NSString *XgridDRMAAAuthenticationMethod;
extern NSString *XgridDRMAANoAuthenticationMethod;
extern NSString *XgridDRMAAPasswordAuthenticationMethod;
extern NSString *XgridDRMAAKerberosAuthenticationMethod;

extern NSString *XgridDRMAAUsername;
extern NSString *XgridDRMAAPassword;

Not all of these need to be set, obviously: for initial development, I’ve just set these values:

defaults write NSGlobalDomain XgridDRMAAIdentificationMethod XgridDRMAANetServiceIdentificationMethod
defaults write NSGlobalDomain XgridDRMAANetServiceName Astor (my G5)
defaults write XgridDRMAAAuthenticationMethod XgridDRMAANoAuthenticationMethod

To respond to Charles’s comment about OCUnit:

For one, I’m right now using OCUnit as a way to automatically run “tests” that aren’t really unit tests, because there are no (or only trivial) OCUnit assertions—they’re just simple short programs with some debugging output. This just means I don’t have to create a separate executable target and manually run that.

As for real unit tests, I think I’m just going to make the assumption that a grid is selected properly via the user defaults mechanism (eventually, through the prefpane) before the tests are run. There’s no reason that someone building the code on their own machine needs to run the unit tests—they can just build the framework target by itself.

3 Responses to ““Contact strings” and browsing for Xgrids”

  1. charles Says:

    Thanks for your answer on OCUnit. I also have some kind of test I can run, but not very thorough and not bound to OCUnit, and thus not automatic. What you are proposing seems very reasonable and I will explore that avenue… Thanks!

  2. charles Says:

    Regarding the connection, I have implemented the following: the only information to give is the address and optionally, the password. Then, one can just call ‘connect:’, and my implementation goes through all the possible connection types (6 total at most), starting with the most likely method (e.g. if a password is given and the address contains dots ‘.’ or is ‘localhost’, first try password authentication on a remote server). Then I can store the info about the successful attempt for next time.
    I don’t think that helps you much, I just thought this is somewhat related to your entry :-)

  3. Bill Van Etten Says:

    I’ve been researching a means to provide my application with access to executing, monitoring, and killing jobs in a DRM-independent sort of way. I’m mostly interested in providing support for SGE, LSF, and Xgrid. Considering DRMAA. Considering it more now that I see DRMAA for Xgrid. I’m wondering how far along you are? I’ve gotten the indication that you’re pretty far along, reading through your BLOG. Thanks for this, BTW.

    Bill

Leave a Reply