some project ideas
Meta-jukebox as service composition example
Make an interface to three/four jukebox systems. One difficulty will
be in defining the schema for the information used: e.g., does it handle
multiple artists (unlike FreeDB/CDDB) and how are well do fields match
('artist / recording' -> 'artist' & 'recording'). Design the jukebox
using two/three pairwise interface transforms rather than a
single 'cannonical' format or interface (requiring three/four interface
transforms).
e.g.,
A, B, C, D:
A <--> B
B <--> C
C <--> D
rather than
A, B, C, D:
A <--> I
B <--> I
C <--> I
D <--> I
Protocol Eavesdropping and Inspection for Service Interface Discovery
Use packet capture and payload analysis tools (which can
be fairly robust if you assume the payload is XML and may utilize
known Schema) to have a client (or proxy for a client) discover
how to interact with some new-found service.
- Backward-compatible with non-introspecting servers/services
- Example: discover various location-based services with simple
interfaces; change the interface and have the user not have
to do anything
Wide-area Indexing applied to distributed file-sharing
Gnutella is broken.
Fix it by adding filtered query flooding
(adapt from the SDS).
RTP profile for actuation
The real-time transport protocol (RTP) has profiles (written as RFCs)
for carrying various data types. e.g., audio, video, text messages,
DTMF (phone tones), etc. It seems to me that there is a need for an
"real-time actuation" RTP profile. The reasoning is that some
actuations -- such as sending commands to pan/tilt/zoom a camera or
move a robot arm -- do not map well to "RPC-style" reliable
semantics. They are unlike the majority of actuations (e.g., setting
temperatures or flipping switches), which are idempotent, not
strongly time-sensitive, and thus well-suited to TCP.
The project would be to design and implement a system that manages
the real-time control loop between user and actuator. The goal is to
dampen oscillations caused by delays in obtaining responses.
Possible approached include 1) adapting the parameters of a filter
that sits between the human control inputs and the actual actuator
controls, and/or 2) predicting intended input based on an estimation
of the round-trip time and the timestamped command streams sent by
the client and received by the server. (or: your idea here)
This could be implemented in the MASH toolkit, which contains RTP
base classes, a camera control client, and an undamped camera control
server.
Having some
background in network protocols and/or control theory might be
helpful. I'm sure there is relevant literature to assist in the
investigation.
Receiver-driven, layered, hierarchically-scoped announcement protocol
for scalable service advertising
(AKA Push (SAP) vs. Pull (DNS) vs. Hybrid for scalable service advertising)
How do we design the advertisment/naming protocol for millions of IP
light bulbs and internet toasters? Just use DNS? Just use SAP? How
about a hybrid of SAP and DNS?
The current SAP spec does not specifiy scoping of services beyond
multicast TTL and administrative scoping. In a world of IP light
bulbs advertising their presence, does this model scale succificently?
Contrast the DNS architecture (pull) to the SAP architecture (push) in
terms of scaling properties (hierarchy) and ability to scope. Given
two "objects" with some location in the naming hierarchy, and scopes
defined by them, can you vary the bandwidth of their advertisements to
each other depending the distance between edges of their scopes or
amount of scope overlap? Can you hybridize the push and pull approach
to allow advertisements to scale sub-linearly with the numbre of
advertised objects. This probably entails advertising directories
rather than individual objects, thus providing the layer of
indirection necessary to impose hierarchy.
Distributed infrastructure for specifying map inclusion area and
object location in those maps.
Maps of different scales have differing precisions in the location
of object they contain. If the location of Soda Hall, for example,
was specified in 8bytes of latitude and 8bytes of longitude (GPS-style),
no matter which map it was represented on, it would look like a *point* --
even on a map that should more reasonably indicate Soda as a blob
with some area (assume circular or retangular rather than as an
arbitrary polygon, i.e., allowing just a lat/long point and radius).
What infrastructure "standard" could be designed to allow arbitrary
netsites to advertise maps that can be embedded in other (unknown)
maps, and can allow objects located in one map to be transfered to
another map while maintaining the "area" covered by these objects.
What are the trade-offs in the choice on 1) requiring objects to
hardcode lat/long *and* radius in all their descriptions versus 2)
inferring the "radius" of objects from the map scale.
Additional issue: maps DBs often define that intersecting sub-maps
share a 2D line (not necessarily straight). This avoids problems
with queris to maps "falling between the cracks" or overlaps
where there should be no overlap. How can a maps that don't know
about each other (i.e., your making a map of your office and want
to include it on smoe other maps, etc.) share these edges?
Interface Description Language augmentation to support model-based
UIs (widget hints):
current IDLs (i.e., the CORBA IDL) specifies only the data types
and paramater passing style for remote object invocation. Model-based
UIs specify the UI widget set in a hierarchy, thus allowing pieces
to be added and removed, and "renders" the hierarchy while maintaining a
set of constraints based on, e.g., sizes of elements and their relative
orientation.
Can these two models be combined in a hybrid that allows both
feature composing of the invocations (RPCs),
and separate subsetting/aggregation
of UI elements
(i.e., make a thing that buffers DNS queries [queries to one object]
through a local cache [another object] the above still maintains
the original UI if it had one)
Using best-effort reservation hints rather than RSVP for IP cellular phones:
can we avoid a payment infrastructure?
Badri has proposed using predicitive service reservations via RSVP
and some notion of an "expected mobility pattern" to create an
IP cell phone network. (Let us ignore guaranteed service.)
I propose avoiding reservations at base stations. They're fundametally
predicitive anyway, and it could be argued that best-effort internet
traffic, and hence reservations, should be treated equally rather
than first-come first-serve. Have clients send periodic (soft-state)
reservation hint requests rather than RSVP reservation requests.
Rather than have these be things return "accepted" or "not accepted,"
what is returned is the current load, and the expected load for
the times during the reservation period including the client request
(thus replies over >1.0 happen, and show when many people will be
fighting for BW sometime.) The server can periodically update the
hints via mcast to interested clients as the reservation
status changes (used in addition to periodic reciever-driven re-queries).
Can this achieve reasonable functionality *without* requiring the
payment infrastructure necessary in an IntServ network (i.e.,
necessary as a dis-incentive for over-reservation)? Definition of
workload, measurements necessary. Claim is that people/applications
can evolve their behavior (application-specific adaption) given the
additional info, and that they will accept this in trade for
non-payment.
Scoping in Service Location Protocol(s)
The SCOPE tag in SLP is under fire on the SLP mailing list. The idea
of this tag is to aggreagate sets of services at a single directory
agent (DA) which is then a "scoped DA."
...
Todd D. Hodes, <mylastname @ myfullname dot org>