Adeona Proxy Experiment

[Glenn Rempe]

Yoshi,

I would like to take a crack at an experimental backend proxy server
that would present the same API as teh SunRPC interface that OpenDHT
presents. The goal would be to present exactly the same interface as
currently exists to allow for a simple repoint of the gateways to this
new service.

The design would have two key elements:

- A thin proxy server which presents the same SunRPC interface as
OpenDHT. It would provide the ability to get or put location
updates. This proxy would be a Ruby Sinatra app which is well suited
to lightweight proxy servers.

- This proxy would talk to an existing key/value store, thus
abstracting the end users entirely from the back end storage
mechanism. I am thinking of looking at several alternatives in this
space including CouchDB, TokyoCabinet, and Google's Big Table (with
the app running in Google App Engine, via JRuby). The abstraction
would allow swapping out the back-end store in the future.

What I need from the Adeona Team
--

I am not a C wiz. I have explored the Adeona source code, and I have
a local bzr branch setup. I would prefer to minimize my involvement
with client changes though, instead focusing on an experimental back-
end. That being said I need someone who is very familiar with the C
source code (especially running on OS X) to give me some guidance and
source/config changes to allow me to do the following:

- I need to be able to run the client on demand against an arbitrary
test server running on an IP/DNS name that I specify (including
localhost). I have not yet had any luck trying to modify the
adeona.options file to talk to a local proxy.
- I need to be able to run the client against this server as often as
I like, posting realistic data. As I would need to post frequently
this should optimally be a single command that I can run to perform a
location update on demand in real time. I cannot rely on waiting for
automatic updates at some random interval when testing.

If you are interested in this approach, please let me know how I can
setup the client to meet these requirements for testing.

Thanks,

Glenn

[Tadayoshi Kohno]

Hi Glenn,

This is great to hear!  Thank you very much for your interest and offer!  I'll try to have one of the original developers contact you out-of-band since they know the system at a source level much better than me.

However, the first question I have is -- what operating system are you running?  The reason being is that one may need to restart the Adeona client after changing the options file.  On OSX, this entails executing the following commands from the command line:

        sudo launchctl stop edu.washington.cs.adeona

        sudo launchctl unload /Library/LaunchDaemons/edu.washington.cs.adeona.plist

        sudo launchctl load /Library/LaunchDaemons/edu.washington.cs.adeona.plist

        sudo launchctl start edu.washington.cs.adeona

As I think you found, one key entry in the options file is GWUPDATE_URL, which specified the URL from which to grab the gateway file.

Another key option is SCHED_LAMBDA.  One can change the update interval by changing SCHED_LAMBDA as follows:

The parameter controlling the inter-update random variable. It is equal to the average number of updates per second. (Multiply by 3600, and one gets the average number of updates per hour.)

Lambda for averaging 1 per 30 seconds is 1 / 30 = .03

Lambda for averaging 1 per 2 minutes is 1 / 120 = 0.00833  (this is probably the most reasonable test value)

Lambda for averaging 1 per 60 minutes is 1 / 3600 = .0002777777

Thanks!

Yoshi

[Glenn Rempe]

On May 20, 12:56 pm, Tadayoshi Kohno <yo...@cs.washington.edu> wrote:
> Hi Glenn,
>
> This is great to hear!  Thank you very much for your interest and  
> offer!  I'll try to have one of the original developers contact you  
> out-of-band since they know the system at a source level much better  
> than me.

Thanks.

>
> However, the first question I have is -- what operating system are you  
> running?  The reason being is that one may need to restart the Adeona  
> client after changing the options file.  On OSX, this entails  
> executing the following commands from the command line:

I am using OS X 10.5.7

>
>          sudo launchctl stop edu.washington.cs.adeona
>          sudo launchctl unload /Library/LaunchDaemons/
> edu.washington.cs.adeona.plist
>          sudo launchctl load /Library/LaunchDaemons/
> edu.washington.cs.adeona.plist
>          sudo launchctl start edu.washington.cs.adeona

Yes, I was aware of this. Based on my brief experiments running only
'sudo launchctl stop edu.washington.cs.adeona' resulted in the adeona
process restarting with a new pid (I could not get it to fully stop
which was the expected result. This may be a bug in the config
file.) Can you confirm that a stop, or a stop + start will force re-
read of the config file? Or is unload/load required? (It should not
be required for a properly operating launchctl config.)

>
> As I think you found, one key entry in the options file is  
> GWUPDATE_URL, which specified the URL from which to grab the gateway  
> file.

I had trouble with changing this. Changing to to www.rempe.us/gateways.adeona
(which is a page I put up to generate a gateway file with only a
single address of 127.0.0.1) resulted in an error in the adeona log
indicating a bad gateway url. This may be a bug.

What triggers a gateway update?
How often will it auto update (if it does while running at all)?
Can you get your client to update from this URL?
Should a gateway update overwrite the gateways config file that gets
installed initially? Or is the update in memory only?

http://www.rempe.us/gateways.adeona

As I understand it using the gateway file as presented in this custom
URL should force the client to attempt to submit to localhost.
Correct?

>
> Another key option is SCHED_LAMBDA.  One can change the update  
> interval by changing SCHED_LAMBDA as follows:
>
>         The parameter controlling the inter-update random variable. It is  
> equal to the average number of updates per second. (Multiply by 3600,  
> and one gets the average number of updates per hour.)
>
>         Lambda for averaging 1 per 30 seconds is 1 / 30 = .03
>         Lambda for averaging 1 per 2 minutes is 1 / 120 = 0.00833  (this is  
> probably the most reasonable test value)
>         Lambda for averaging 1 per 60 minutes is 1 / 3600 = .0002777777

Thanks. That is helpful. I will try.

>
> Thanks!
> Yoshi

No Problem. I make no promises for success. I will let you know if
the approach looks promising or runs into snags though.

[David Nason]

Hi Glenn,

No, the entry in gateways.adeona has to be an external IP address or
URL. Don't forget about port 5852.

David

[Adeona Team]

Hello Glenn,

Thanks for working on a backend proxy server. As far as I can think
of, there are three ways one can go about testing remote storage code
for Adeona,

==> Use OpenDHT's gateway_test.c code

The instructions are located at

http://www.opendht.org/users-guide.html

...under the Sun RPC Syntax section.


==> Use Adeona's test code

Assuming the adeona-0.2.1.tar.gz source tarball

1. Modify line 226 of the Makefile like below

all : $(DHT_EXE)

2. make

3. The previous step should produce a test_opendht.exe program
-> It takes a random node from resources/gateways.adeona and does a
put/get test (i.e., check if what it put is what it got)
-> If you modify your gateways.adeona to only contain your server then
it should connect to that (or you can hard code your server into the
test code)

4. For more details, the relevant routine is test_putget() in opendht/
opendht_test.c
-> If you decide to go this route and need help modifying the test
program to do as you like, please let me know.

==> Modify the Adeona client

1. Comment out lines 79 to 109 in app/client.c
i.e., the while block that makes the client sleep and the if block
that checks if you have an IP address

2. gateways.adeona should contain your server

3. set USE_GWUPDATE = 0 in resource/options.adeona

4. Run the client which should not sleep and just keep going through
states

./adeona-client.exe -r resources/ -s adeona-clientstate.cst

Thanks,
Gabriel

[Glenn Rempe]

Thanks Gabriel. I'll take a look.

G

[Glenn Rempe]

Hi Gabriel,

I was taking a look at your suggestions and ran into some issues.
Perhaps you can take a look?

See comments below:

On May 22, 12:55 pm, Adeona Team <ade...@cs.washington.edu> wrote:

> Hello Glenn,
>
> Thanks for working on a backend proxy server. As far as I can think
> of, there are three ways one can go about testing remote storage code
> for Adeona,
>
> ==> Use OpenDHT's gateway_test.c code
>
> The instructions are located at
>
> http://www.opendht.org/users-guide.html
>
> ...under the Sun RPC Syntax section.

Note that I am working from a checkout of the official bzr source
repo.

The instructions on this page seem to be out of date. There is no
file to match the suggestion (gateway_test.c is not to be found in the
repo) so I could only complete the first rpcgen steps.

$ gcc -c gateway_test.c

>
> ==> Use Adeona's test code
>
> Assuming the adeona-0.2.1.tar.gz source tarball
>
> 1. Modify line 226 of the Makefile like below
>
> all : $(DHT_EXE)

Can you please provide some more code context for this change? Line
226 in bzr is a comment.

http://bazaar.launchpad.net/%7Ebalkan/adeona/trunk/annotate/head%3A/Makefile

>
> 2. make
>
> 3. The previous step should produce a test_opendht.exe program
> -> It takes a random node from resources/gateways.adeona and does a
> put/get test (i.e., check if what it put is what it got)
> -> If you modify your gateways.adeona to only contain your server then
> it should connect to that (or you can hard code your server into the
> test code)
>
> 4. For more details, the relevant routine is test_putget() in opendht/
> opendht_test.c
> -> If you decide to go this route and need help modifying the test
> program to do as you like, please let me know.
>
> ==> Modify the Adeona client
>
> 1. Comment out lines 79 to 109 in app/client.c
> i.e., the while block that makes the client sleep and the if block
> that checks if you have an IP address

Do you actually mean lines 116:146 in this commit?

http://bazaar.launchpad.net/%7Ebalkan/adeona/trunk/annotate/head%3A/app/client.c

[David Nason]

Glenn,

I just sent a copy of gateway_test.c for Gabriel's alternative #1 to
your direct email.

The line Gabriel is referring to in alternative #2 is line 263. In
any case, just search for "all : " - this will create test_opendht.exe.

And alternative #3 is the complete while and if blocks that you are
seeing on lines 116:146.

David


-----Original Message-----
From: adeona-d...@googlegroups.com
[mailto:adeona-d...@googlegroups.com] On Behalf Of Glenn Rempe
Sent: Saturday, May 23, 2009 1:56 PM
To: adeona-developers
Subject: [adeona-developers] Re: Adeona Proxy Experiment

[Adeona Team]

Hello Glenn,

Sorry, I wasn't aware you were using the launchpad repo.

David is right about the line numbers, line 263 for the Makefile
change and lines 116 - 146 for the client.c changes.

For option 1, to be more detailed,

1. Download the following files
http://www.opendht.org/gateway_prot.x
http://www.opendht.org/gateway_test.c

2. Run the following commands
$ rpcgen -h gateway_prot.x > gateway_prot.h
$ rpcgen -l gateway_prot.x > gateway_prot_clnt.c
$ rpcgen -c gateway_prot.x > gateway_prot_xdr.c
$ gcc -c gateway_test.c
$ gcc -c gateway_prot_clnt.c
$ gcc -c gateway_prot_xdr.c
$ gcc -o gateway_test gateway_test.o gateway_prot_clnt.o
gateway_prot_xdr.o

3. On OS X, you will get warnings but they should be okay

4. You should be able to run
./gateway_test your.server.com port

Thanks,
Gabriel

> http://bazaar.launchpad.net/%7Ebalkan/adeona/trunk/annotate/head%3A/M...

>
> > 2. make
>
> > 3. The previous step should produce a test_opendht.exe program
> > -> It takes a random node from resources/gateways.adeona and does a
> > put/get test (i.e., check if what it put is what it got)
> > -> If you modify your gateways.adeona to only contain your server then
> > it should connect to that (or you can hard code your server into the
> > test code)
>
> > 4. For more details, the relevant routine is test_putget() in opendht/
> > opendht_test.c
> > -> If you decide to go this route and need help modifying the test
> > program to do as you like, please let me know.
>
> > ==> Modify the Adeona client
>
> > 1. Comment out lines 79  to 109 in app/client.c
> > i.e., the while block that makes the client sleep and the if block
> > that checks if you have an IP address
>
> Do you actually mean lines 116:146 in this commit?
>

> http://bazaar.launchpad.net/%7Ebalkan/adeona/trunk/annotate/head%3A/a...