<someone> wrote:
>
> WebFunds won't work on our development machines.
>
> Because we're on a 10.0.0.0 network hidden from
> the world.
>
> ah. how tough is it going to be to stick a proxy
> support in there?
There are several answers to this, none are necessarily comprehensive...
Ask your sysadm to
This FAQ explains how to set up the proxy within the JVM:
http://www.ibiblio.org/javafaq/javafaq.html#proxy
Let us know if it works. SOX over socks is definately a cool feature to have.
The code is in there to set up the properties, so in the startup run file or doze equivalent add the flags:
-pb true -ph hostname -pp portnum
(once only, it should store the flags in the properties file, which is located at user/props.dat )
However the properties are currently ignored by the socket code.
> What protocol should the proxy be expecting once
> it has made the connection?
HTTP is used at the moment. That is, all requests should look like web GETs or POSTs.
One of the attributes of the WebFunds value system is that the assets are the owners are the accounts. That means that if you lose your machine, you lose the value.
To solve this, take backups.
Click on the File menu option at the top,
and then click on Backup. This will pop
up an Explorer style dialog, which asks where to store
the backup.
Select a directory name somewhere (must exist), for example
a different disk or removable media. Then click on
Select Dir for Backup
and the backup routine will make a copy of your user directory
into the selected directory, under a name starting with WF_.
Click on the File menu option at the top,
and then click on Recover Backup.
This will guide you through the selection of the location
of a backup to recover from.
Once the recovery is complete, it will cause WebFunds to stop, and you will have to restart it.
Alternatively, take a new copy of WebFunds and start it up. Then, it will offer you a choice of recovery or new user. If you then recover from a backup, you can proceed to use that recovered user.
The above backup routine copies the entire WebFunds directory into
a directory that is named like WF_1234567890, all
within the directory you selected. The coded name is then recognised
by WebFunds when a recovery is done.
The backup will include all the JARs and scripts and anything else in the WebFunds directory. This way, the entire program is also backed up, so that there is no problem with reading the data at a later time.
When the recovery is done, only the user data is recovered,
being the data within the user directory. This is
possible because it is assumed that you already have a running
WebFunds program in order to do the recovery.
You could just as well run the entire program within the backup directory, and in this case, there would be no recovery needed.
The following steps are suggested for the advanced user only.
If a manual backup is desired, to save space for example,
simply take a copy of the contents of the user
directory. Recovery can be done by selecting that directory,
but WebFunds will check before proceeding, as it will not
recognise the parent directory.
If you require a very small backup, then you might consider copying the account key files. These are named as:
user/data2/WalletManager/Wallet/Accounts/abc123...
where the Wallet component will be
SOX or Trader,
and the account name at the end is the hash
of the public key.
But, bear in mind that such a procedure is a developer procedure only, and you will require expert help in order to recover afterwards, if it is possible at all. You should practice this before ever relying upon it.
> I thought that generating a cheque didn't require
> a connection to the outside world, but the Wallet
> still tries to make one - what is going on here?
A SOX payment, or cheque, is timestamped. But, the time used is that of the server (of course!); as there is mighty suspicion of local time, and no good feeling for whether the user has set up local time to even be in the right year, the protocol goes out to get a time check.
Once a time syncronisation is achieved, it will use that, more or less, for future cheques.
As an aside, the purpose of setting tight paramaters is to permit a client like WebFunds to cancel cheques that are expired, so as to 'reclaim' the value. Once the payment is expired, WebFunds knows it will never be cashed, and can safely cancel it. This feature is not implemented as yet, but will be one day.
> And why does generating the cheque succeed even though
> the Wallet can't connect to the outside world?
If it fails to get the syncrisation time, SOX just sets the paramaters for cheque writing to be rather wide. Basically, from 0 to some time in the future, and it hopes you have not set your clock to something really wierd.
If indeed it gets the times wrong, then the cheque will fail as being 'expired' or, more rarely, 'too early'. Once the protocol has acheived time syncronisation, all these difficulties should disappear.
> When I connect a browser to the page that the
> Wallet is trying to open I get cypherpunks.ai -
> is that correct?
That is approximately correct. The protocol wishes to talk to the server for that contract. Assuming that we are talking about Glitter here, that contract states where the server is located in a Glitter.loc file within the contract store.
In that file, there is a reference to the SOX Server Descriptor, or SSD. The SSD is just an intermediate file that tells all about the server. It is a web file, located on both www.systemics.com and www.webfunds.org (which latter is currently hosted on the machine known as cypherpunks.ai, a repository for cool projects based out of the financial cryptography centre of Anguilla). In that file, the SSD, there are the URLs for the server proper.
Once the protocol gets the SSD, it will cache that (until it gets suspicious as to whether the server is there, in which case it will try an update).
Once the SSD is acquired, then it will have the actual server URLs, and the protocol can go there directly. Which is, as of the moment, at somewhere like http://hayek.ai:8???/