Registering your service
You must register your service name with us before attempting
to add a new service; otherwise, service registration will fail. To
register your service, please contact us.
We will require some additional information from you. As an example,
CoralCDN's service policy uses the following:
KnownService coralcdn
DomainAlias nyud.net coralcdn
DomainAlias nyucd.net coralcdn
SortType latencycap
MaxAddrRec 2
MinAddrRec 1
AddrRecTTL 60
This policy says that CoralCDN wants OASIS to return between 1 and 2
address records per DNS request, each with TTL of 60 seconds, using
the "latencycap" policy for server selection. This default policy
prefers nodes based on locality, unless the nearer node is overloaded
(load >= capacity).
Our NSDI '06
paper describes several techniques to integrate OASIS using its
DNS, RPC, or HTTP interfaces; the simplest way is for users to just
then issue a DNS query to coralcdn.nyuld.net, using the above
example.
OASIS does support aliases, which use longest suffix matching, so
users could also issue requests to *.nyud.net given the above
configuration (e.g., example.net.nyud.net). To support this aliasing,
you simply must point the NS records for your domain (nyud.net, in
this example) to OASIS's nameservers. For a list of OASIS's primary
nameservers, please see whois nyuld.net.
Integrating your local application
To integrate your local application with the OASIS replica, your
application simply needs to listen on a TCP server socket on the
configured port (LocalServicePort). Then, when the local
OASIS replica connects to your application, simple accept the
connection, immediately send the following 12 bytes of data (all in
network-byte order), then close the connection.
struct oasserv_localapp_res {
u_int32_t srvid;
u_int32_t load;
u_int32_t cap;
};
where srvid is your "secret code", given in
oasissrv.services.conf, load is your process's
current load, and cap is your process's load capacity. To
just "get it working" with OASIS's latency-based server selection, you
can always provide a load of 1 and capacity of 10. By default, your
application will get such a "keepalive" connection from the OASIS
replica once every 15 seconds.
If you are looking to adopt OASIS for your system deployed on
PlanetLab, you only need to follow these integration instructions
(i.e., listen on a local TCP socket): An OASIS replica is already
running on most PlanetLab hosts as a public service we offer the
PlanetLab community.
Source code for integrating your local application
While integrating OASIS into your applications really is quite easy,
please find below some links to some existing code that might prove
useful.
- Libasync-based C++: For applications also using SFS's
libasync libraries, the OASIS CVS repository described above includes
the files utils/regapp.[hC] to easily integrate OASIS.
- SEDA-based Java: The Bamboo Java code for OpenDHT integrates OASIS as a SEDA
stage. Please look for src/bamboo/util/Oasis.java in
the Bamboo CVS
snapshot as of March 3, 2006.
- Apache module in C: The Na Kika project adopts
OASIS as an Apache module for their Apache-based web proxies. Please
see here for
a tar ball of this mod_oasis, written in C.
If you think the code you write to integrate OASIS into your
application may be useful for others (based on your programming
language and/or environment), please contact us and we'll add it to
this page.
NYU Secure Computer Systems
/
Project IRIS
·
7th Floor · 715 Broadway ·
New York, NY 10003 · USA
