Multiple people can't remember the name rockhound.

In retrospect, I don't like having the name of the service tied to the stone metaphor. If it's going to exist as an independent research vector, and I hope it does extend the PDS work we did, I want it to have a better name.

I thought something that wouldn't be out of place in the “cloud computing” space would be nice.

So, I've come up with the new name.

Rockhound is now Drift. I was thinking about “spindrift”, forming a loose acronym from some of the words describing its intended qualities: scalable, proactive, namespace, distributed. However, a visit to the Wikipedia page for "drift" revealed that the word actually has multiple connotations that make a lot of sense for this service. In particular, the notion that Drift encapsulates the relative divergence of information state between two endpoints (as in clock drift), I think, makes it a nice, flexible name.

I am also switching to git for version-control for drift. I'll make the repository information public, soon.

As I recall, the original plan for a demo at SC07 was to somehow pipe the statistics generated by our experimental setup through an Eclipse plugin. Since I can't think of a reason why doing this in Eclipse makes any sense at all, I came up with something different.

In this setup:

• Stats are collected through EVpath control channels and aggregated at a central location, which is:
• An Apache (or other compliant) HTTPD server module. This module converts the statistics into running graphs, generating JPG/PNG/animated GIF on the fly. The module also registers some URLs with the server so it can intercept them, sending the graph images to:
• A web page running in a standard browser. This page can either be static, in which case updated graphs can be obtained through reload or timeout-refresh, or we can introduce some javascript and do some AJAX-style asynchronous requests to the server for new pictures.

Notes:

• We wouldn't have to do graphics straightaway - we could just display the raw numbers at the webpage and introduce graphics later.
• This provides an easier path to introduce control and adaptation from the display, or from any other agent that can do HTTP GET/PUT.
• No JNI, no wonky Eclipse weirdness.
• The Best Part - do this and people don't have to come to us to see the demo. We provide them with the URL of the display page, and they can see it from THEIR booth/airport/bathroom/WHATEVER.

OK, give it the business.

~~DISCUSSION~~

From Matt Wolf:

I talked to Wu Feng at this conference… He has an interesting project looking at semantic storage. http://www.cels.anl.gov/events/conferences/SC07/presentations/paramedic-flyer.pdf He won the storage challenge last year with it, so some/all of you may already have known that…

Anyway, from discussions with him, ParaMEDIC might plug in quite nicely with the structured stream metadata extension “stuff” we've been talking about. He uses an application-specific data parser to generate enormous data size reductions for the the transmission of data to the store, and then uses a lossless re-inflation technique on the far side. He's targeting the bio-informatics end of things… but could be interesting. And he's open to thoughts of collaboration.

Matt

~~DISCUSSION~~

Matt Wolf on next steps for HECURA after the summer 08 FSIO meeting.

Hi,

Just a quick summary to make sure everyone's in the loop – it was really good to see both of you, Patrick & Patrick. I hope you both had a good trip back to NM!

1) We're going to do a very minimal pass over the cluster text and submit it to eScience on Sunday. Patrick Widener has the ticket on that.

2) For next semester, we'd like a bi-weekly phone call. Time suggestions?

3) We need to pick out what the next publishable increment is. One suggestion is to focus on the autonomic part – looking at how to declare the policy, parse it into particular reservations of execution environments in the IOGraph and the metabots, and make resource decisions for throughput, etc. Feeling is that we need to jump-start this with some in-person time – Patrick & Mary will plan to try to come over to ATL sometime in late September or so for several days of focused work. We need to get a travel plan for the GT delegation to visit Albuquerque, too.

4) We need to nail down what student is working on what part of the project this semester. Hasan's lined up well on dataTap; my thought was that Fang might be well positioned to take over more of the IOGraph work after his time in measurement, etc. at Oak Ridge. Particularly since it seems Scott McManus may be moving more in the cloud direction.

5) The next HECURA FSIO call will be coming out sometime in Fall, with a due date probably early next calendar year. There seemed to be general agreement to try to do a renewal together – we should think strategically in terms of what we'd like to do with the next round and what we might do between now & January to help cement that story.

~~DISCUSSION~~

Ron Oldfield on restructuring LWFS:

One of the things I would like to complete in the next few months is to make LWFS open source. Right now, LWFS has a bunch of stuff that needs to be pulled out before we can do that. I would also like to clean up the basic structure of LWFS while we're at it.

So, here's a first-draft plan at restructuring LWFS:

Main LWFS repository (open to all)

 lwfs
     support (remove hashtable, lists, and perhaps a few other unused pieces)
     admin (lwfs-start, lwfs-kill, lwfs-ping, ...)
     rpc (client and server code to support data movement)
     txn (code to support distributed transactions)
     svc (supported lwfs services -- client and server code combined)
         authn (authentication)
         authr (authorization)
         storage
         naming

 doc (autogenerated API document)

 tests (regression tests)

Other repositories (mostly restricted to developers/authors):

 lwfs-papers (for lwfs developer/authors only)

 lwfs-libsysio (libsysio wrappers for LWFS)

 lwfs-fuse (FUSE wrappers for LWFS)

 lwfs-performance (benchmark codes and results for LWFS ... may make public)

We should probably get the transaction and IB stuff integrated into the main repo before we do this.

Any comments on the plan? I expect Todd to come at me with a hammer any minute now?

I hope to use this to develop a HTTPD-based demo for IOgraphs at SC08.

 
#include "httpd.h"  
#include "http_config.h"  
#include "http_request.h"  
#include "http_protocol.h"  
#include "http_core.h"  
#include "http_main.h" 
#include "http_log.h"  
 
/* 
 * C version of chapter 9's Apache::SendFile
 * note: this does less than http_core.c:default_handler()
 * it is meant to be educational, and/or possibly a template
 * to alter behavior of default_handler()
 */ 
 
static int sendfile_handler(request_rec *r)
{
    int rc;
    FILE *f;
 
    if ((rc = ap_discard_request_body(r)) != OK) {
        return rc;
    }
 
    if (r->method_number == M_INVALID) {
	ap_log_rerror(APLOG_MARK, APLOG_NOERRNO|APLOG_ERR, r,
		    "Invalid method in request %s", r->the_request);
	return NOT_IMPLEMENTED;
    }
    if (r->method_number == M_OPTIONS) {
        return DECLINED;
    }
    if (r->method_number == M_PUT) {
        return METHOD_NOT_ALLOWED;
    }
 
    if (r->finfo.st_mode == 0 || (r->path_info && *r->path_info)) {
	char *emsg;
 
	emsg = "File does not exist: ";
	if (r->path_info == NULL) {
	    emsg = ap_pstrcat(r->pool, emsg, r->filename, NULL);
	}
	else {
	    emsg = ap_pstrcat(r->pool, emsg, r->filename, r->path_info, NULL);
	}
	ap_log_rerror(APLOG_MARK, APLOG_ERR|APLOG_NOERRNO, r, emsg);
	return HTTP_NOT_FOUND;
    }
    if (r->method_number != M_GET) {
        return METHOD_NOT_ALLOWED;
    }
 
#if defined(OS2) || defined(WIN32)
    /* Need binary mode for OS/2 */
    f = ap_pfopen(r->pool, r->filename, "rb");
#else
    f = ap_pfopen(r->pool, r->filename, "r");
#endif
 
    if (f == NULL) {
        ap_log_rerror(APLOG_MARK, APLOG_ERR, r,
		     "file permissions deny server access: %s", r->filename);
        return FORBIDDEN;
    }
 
    ap_update_mtime(r, r->finfo.st_mtime);
    ap_set_last_modified(r);
    ap_set_etag(r);
 
    if (((rc = ap_meets_conditions(r)) != OK)
	|| (rc = ap_set_content_length(r, r->finfo.st_size))) {
        return rc;
    }
 
    ap_send_http_header(r);
 
    if (!r->header_only) {
	ap_send_fd(f, r);
    }
 
    ap_pfclose(r->pool, f);
    return OK;
}
 
static const handler_rec sendfile_handlers[] = { 
    { "*/*", sendfile_handler }, 
    { NULL }
};
 
module MODULE_VAR_EXPORT sendfile_module = {
    STANDARD_MODULE_STUFF, 
    NULL,                  /* module initializer                  */
    NULL,                  /* create per-dir    config structures */
    NULL,                  /* merge  per-dir    config structures */
    NULL,                  /* create per-server config structures */
    NULL,                  /* merge  per-server config structures */
    NULL,                  /* table of config file commands       */
    sendfile_handlers,       /* [#8] MIME-typed-dispatched handlers */
    NULL,                  /* [#1] URI to filename translation    */
    NULL,                  /* [#4] validate user id from request  */
    NULL,                  /* [#5] check if the user is ok _here_ */
    NULL,                  /* [#3] check access by host address   */
    NULL,                  /* [#6] determine MIME type            */
    NULL,                  /* [#7] pre-run fixups                 */
    NULL,                  /* [#9] log a transaction              */
    NULL,                  /* [#2] header parser                  */
    NULL,                  /* child_init                          */
    NULL,                  /* child_exit                          */
    NULL                   /* [#0] post read-request              */
};

~~DISCUSSION~~

Attached are links to 3 theory papers on sensor networks.

1) This is the paper that defined the grid model: sensors are on a grid and the adversary can take over a certain fraction of the nodes in a fixed box. The problem addressed in this model in all 3 of these papers is how to broadcast a message reliable from a base station to all nodes in the network.

Broadcast in radio networks tolerating byzantine adversarial behavior

http://delivery.acm.org/10.1145/1020000/1011807/p275-koo.pdf?key1=1011807&key2=2446486121&coll=GUIDE&dl=GUIDE&CFID=79035950&CFTOKEN=37312310

2) This is a followup paper that deals with a certain type of attack: adversary use collisions to inhibit communication:

Reliable broadcast in radio networks: the bounded collision case

http://www.cs.umd.edu/~cykoo/podc06.pdf

3) This is our followup paper that shows how to get both robustness and energy-efficiency

Sleeping on the Job: Energy-Efficient and Robust Broadcast for Radio Networks” by Valerie King, Cynthia Phillips, Jared Saia and Maxwell Young To appear in Principles of Distributed Computing (PODC), 2008.

http://www.cs.unm.edu/~saia/papers/sleeping.pdf

~~DISCUSSION~~

Hermes is really geared towards a plugable, distributed pub/sub interface with stateful subscriptions. In the model, the user provides a utility-based subscription (things like a weighting of relevance, timeliness, and thoroughness of data), which then goes through a pluggable parsing interface. The output of this parser is a logical dependency graph for a trail of function needed to achieve that subscription, but with the functions only resolved down to a symbolic level. (ie sum() instead of a literal chunk of COD code)

This graph form then gets sent to a planner/mapper. The planner interacts with a library repository in order to expand out symbolic functions to a list of possible instantiations (COD with or without specializations, dll for a particular platform, wrapper for a web service call, etc.). These may be graphs in their own right as well (enabling the application to provide preformed “widget” functionality). The planner also queries an execution metadata service that monitors the current execution environment – both locations of worker nodes and the particular gateways and transformation/annotation functions on them. The planner then is responsible for choosing an ordering of the graph, potentially re-using existing functions, and utilizes the amaze layer to place service requests.

The big hiccup to keep in mind is that we're intending this to be done in a cloud/p2p type model. There will be many planner nodes in the system, and they will have only partial metadata access between the planners. Ideally, planning is a service which can migrate dynamically, using some sort of leader-election scheme (although that's not a first-paper priority), and it should integrate tightly with a distributed metadata access layer that has some trade-offs in availability vs accuracy of data (ie chord-like guarantees of eventual data return, overlaid with some fastbit-like data-rich quick indexing).

So… that said, I think rockhound could be used within any or all of the external services that the planner needs. The library function maintenance is a clear example of something that we did with PDS and could do better now. It demands a hierarchical name space, but the ability to farm out particular specialized versions of code to locations which are “near” where those specializations are needed would be very interesting. Potential for doing some of the precached messaging Karsten's been so interested in motivation.

Also, the execution metatdata service is a clear winner… it's the user-space monitoring solution all over again. So that fits cleanly in some of your discussion around rockhoud, too. If we can figure out a way to tie it together cleanly with amaze (which is in cvs, if I didn't mention that to you already) so that you can have multiple agents issuing the graph configuration calls while maintaining a synchronizable view of the total environment… I think that gets awfully close to where you were proposing to go with rockhound, too. And pretty close to what Vibhore said he wanted to do, too.

So, here are some (more) technical questions. You could play most all of these games with some suitably complex naming games – distinguishable provenance-preserving names for each emitted data element, prefix searches for planning, etc. Or you could take a more OO stance and talk about distributed object instantiation, etc. which also boils down to naming, but in a more controllable fashion. Or you could go all the way to dhts and flat name spaces and just focus on limited categories of metadata tagging, with anything fancier having to boot out on a web service call to a much heavier-duty, xml-based coordinator. Do you have thoughts on both (a) general performance guides and (b) personal interest in any of these approaches?

~~DISCUSSION~~

This report from Matt's students at GT details a use case for a group information service, and is sort of a base case for the functionality that Rockhound will need to provide.

~~DISCUSSION~~