Suggestion: a priority for 0.5.2, along with probabilistic caching,
should be to separate Fproxy/mainport/etc from Fred, to run in two
separate VMs.

Pro:
* The thread-limit - each HTTP connection costs a connection, and we
  cannot afford them, because we can't use as many threads in a single
  VM as we want to. To get reasonable performance from Fproxy, I set my
  browser to use _a lot_ of connections. Each one uses a node-side
  thread. Splitfile requests are even worse. And FEC decodes run in the
  Fred VM. More threads means more connections, which means better
  ability to handle load, connections are kept open longer, hop time
  goes down.
* In general, Fproxy etc wouldn't interfere with Fred's resources
* Possible to restart Fproxy without restarting Fred
* Easier to implement alternate interfaces such as a browser plugin if
  _everything_ is exposed by FCP.
* Easier to make alternate implementations of the node. Or make radical
  changes to Fred without making corresponding changes to Fproxy - for
  example, the long-heralded nio.
* People who only use third party FCP clients don't need to run the
  Fproxy VM at all.
* Possible to create a package with only the node, and a package with
  only Fproxy, if wanted.
* Considerably easier to run the client side on a different machine to
  the server side.

Difficulties:
* We need to move perturbHTL somewhere where it can be used by both the
  node (to perturb HTLs of individual FCP messages)
* We need a Main class for running the default servlets etc.
* We need to separate out the two configs.
* We need to expose everything that the servlets have access to over
  FCP.
* We need to ensure that BOTH VMs are started on startup by default, by
  both the Windows and Unix installers.
* Upgrading from the current system to a system with two VMs needs to be
  as automated as possible.

* Probably more...

Comments?
-- 
Matthew Toseland
[EMAIL PROTECTED][EMAIL PROTECTED]
Full time freenet hacker.
http://freenetproject.org/
Freenet Distribution Node (temporary) at http://amphibian.dyndns.org:8889/KHdtkpR1UhY/
ICTHUS.

Attachment: msg06644/pgp00000.pgp
Description: PGP signature

Reply via email to