2004-04-08 04:41:54 +00:00
|
|
|
package net.i2p.data.i2np;
|
|
|
|
|
/*
|
|
|
|
|
* free (adj.): unencumbered; not under the control of others
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
* Written by jrandom in 2003 and released into the public domain
|
|
|
|
|
* with no warranty of any kind, either expressed or implied.
|
|
|
|
|
* It probably won't make your computer catch on fire, or eat
|
2004-04-08 04:41:54 +00:00
|
|
|
* your children, but it might. Use at your own risk.
|
|
|
|
|
*
|
|
|
|
|
*/
|
|
|
|
|
|
2004-04-10 11:39:00 +00:00
|
|
|
import java.io.IOException;
|
2004-04-08 04:41:54 +00:00
|
|
|
import java.io.InputStream;
|
|
|
|
|
import java.io.OutputStream;
|
2004-04-10 11:39:00 +00:00
|
|
|
import java.util.Date;
|
2004-04-08 04:41:54 +00:00
|
|
|
|
2004-04-10 11:39:00 +00:00
|
|
|
import net.i2p.data.Certificate;
|
|
|
|
|
import net.i2p.data.DataFormatException;
|
2004-04-08 04:41:54 +00:00
|
|
|
import net.i2p.data.DataHelper;
|
|
|
|
|
import net.i2p.data.DataStructureImpl;
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
import net.i2p.router.RouterContext;
|
2004-05-17 03:38:53 +00:00
|
|
|
import net.i2p.util.Log;
|
2004-04-08 04:41:54 +00:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Contains one deliverable message encrypted to a router along with instructions
|
|
|
|
|
* and a certificate 'paying for' the delivery.
|
|
|
|
|
*
|
|
|
|
|
* @author jrandom
|
|
|
|
|
*/
|
|
|
|
|
public class GarlicClove extends DataStructureImpl {
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
private Log _log;
|
|
|
|
|
private RouterContext _context;
|
2004-04-08 04:41:54 +00:00
|
|
|
private DeliveryInstructions _instructions;
|
|
|
|
|
private I2NPMessage _msg;
|
|
|
|
|
private long _cloveId;
|
|
|
|
|
private Date _expiration;
|
|
|
|
|
private Certificate _certificate;
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
private I2NPMessageHandler _handler;
|
2004-04-08 04:41:54 +00:00
|
|
|
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
public GarlicClove(RouterContext context) {
|
|
|
|
|
_context = context;
|
|
|
|
|
_log = context.logManager().getLog(GarlicClove.class);
|
|
|
|
|
_handler = new I2NPMessageHandler(context);
|
|
|
|
|
setInstructions(null);
|
|
|
|
|
setData(null);
|
|
|
|
|
setCloveId(-1);
|
|
|
|
|
setExpiration(null);
|
|
|
|
|
setCertificate(null);
|
2004-04-08 04:41:54 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
public DeliveryInstructions getInstructions() { return _instructions; }
|
|
|
|
|
public void setInstructions(DeliveryInstructions instr) { _instructions = instr; }
|
|
|
|
|
public I2NPMessage getData() { return _msg; }
|
|
|
|
|
public void setData(I2NPMessage msg) { _msg = msg; }
|
|
|
|
|
public long getCloveId() { return _cloveId; }
|
|
|
|
|
public void setCloveId(long id) { _cloveId = id; }
|
|
|
|
|
public Date getExpiration() { return _expiration; }
|
|
|
|
|
public void setExpiration(Date exp) { _expiration = exp; }
|
|
|
|
|
public Certificate getCertificate() { return _certificate; }
|
|
|
|
|
public void setCertificate(Certificate cert) { _certificate = cert; }
|
|
|
|
|
|
|
|
|
|
public void readBytes(InputStream in) throws DataFormatException, IOException {
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
_instructions = new DeliveryInstructions();
|
|
|
|
|
_instructions.readBytes(in);
|
2004-04-27 08:41:38 +00:00
|
|
|
if (_log.shouldLog(Log.DEBUG))
|
|
|
|
|
_log.debug("Read instructions: " + _instructions);
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
try {
|
|
|
|
|
_msg = _handler.readMessage(in);
|
|
|
|
|
} catch (I2NPMessageException ime) {
|
|
|
|
|
throw new DataFormatException("Unable to read the message from a garlic clove", ime);
|
|
|
|
|
}
|
|
|
|
|
_cloveId = DataHelper.readLong(in, 4);
|
|
|
|
|
_expiration = DataHelper.readDate(in);
|
2004-04-27 08:41:38 +00:00
|
|
|
if (_log.shouldLog(Log.DEBUG))
|
|
|
|
|
_log.debug("CloveID read: " + _cloveId + " expiration read: " + _expiration);
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
_certificate = new Certificate();
|
|
|
|
|
_certificate.readBytes(in);
|
2004-04-27 08:41:38 +00:00
|
|
|
if (_log.shouldLog(Log.DEBUG))
|
|
|
|
|
_log.debug("Read cert: " + _certificate);
|
2004-04-08 04:41:54 +00:00
|
|
|
}
|
2004-11-02 08:27:55 +00:00
|
|
|
|
|
|
|
|
public int readBytes(byte source[], int offset) throws DataFormatException {
|
|
|
|
|
int cur = offset;
|
|
|
|
|
_instructions = new DeliveryInstructions();
|
|
|
|
|
cur += _instructions.readBytes(source, cur);
|
|
|
|
|
if (_log.shouldLog(Log.DEBUG))
|
|
|
|
|
_log.debug("Read instructions: " + _instructions);
|
|
|
|
|
try {
|
|
|
|
|
cur += _handler.readMessage(source, cur);
|
|
|
|
|
_msg = _handler.lastRead();
|
|
|
|
|
} catch (I2NPMessageException ime) {
|
|
|
|
|
throw new DataFormatException("Unable to read the message from a garlic clove", ime);
|
|
|
|
|
} catch (IOException ioe) {
|
|
|
|
|
throw new DataFormatException("Not enough data to read the clove", ioe);
|
|
|
|
|
}
|
|
|
|
|
_cloveId = DataHelper.fromLong(source, cur, 4);
|
|
|
|
|
cur += 4;
|
|
|
|
|
_expiration = DataHelper.fromDate(source, cur);
|
|
|
|
|
cur += DataHelper.DATE_LENGTH;
|
|
|
|
|
if (_log.shouldLog(Log.DEBUG))
|
|
|
|
|
_log.debug("CloveID read: " + _cloveId + " expiration read: " + _expiration);
|
|
|
|
|
_certificate = new Certificate();
|
|
|
|
|
cur += _certificate.readBytes(source, cur);
|
|
|
|
|
if (_log.shouldLog(Log.DEBUG))
|
|
|
|
|
_log.debug("Read cert: " + _certificate);
|
|
|
|
|
return cur - offset;
|
|
|
|
|
}
|
|
|
|
|
|
2004-04-08 04:41:54 +00:00
|
|
|
|
|
|
|
|
public void writeBytes(OutputStream out) throws DataFormatException, IOException {
|
2005-07-23 00:15:56 +00:00
|
|
|
StringBuffer error = null;
|
|
|
|
|
if (_instructions == null) {
|
|
|
|
|
if (error == null) error = new StringBuffer();
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
error.append("No instructions ");
|
2005-07-23 00:15:56 +00:00
|
|
|
}
|
|
|
|
|
if (_msg == null) {
|
|
|
|
|
if (error == null) error = new StringBuffer();
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
error.append("No message ");
|
2005-07-23 00:15:56 +00:00
|
|
|
}
|
|
|
|
|
if (_cloveId < 0) {
|
|
|
|
|
if (error == null) error = new StringBuffer();
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
error.append("CloveID < 0 [").append(_cloveId).append("] ");
|
2005-07-23 00:15:56 +00:00
|
|
|
}
|
|
|
|
|
if (_expiration == null) {
|
|
|
|
|
if (error == null) error = new StringBuffer();
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
error.append("Expiration is null ");
|
2005-07-23 00:15:56 +00:00
|
|
|
}
|
|
|
|
|
if (_certificate == null) {
|
|
|
|
|
if (error == null) error = new StringBuffer();
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
error.append("Certificate is null ");
|
2005-07-23 00:15:56 +00:00
|
|
|
}
|
2004-07-27 22:04:02 +00:00
|
|
|
|
2005-07-23 00:15:56 +00:00
|
|
|
if ( (error != null) && (error.length() > 0) )
|
2004-07-27 22:04:02 +00:00
|
|
|
throw new DataFormatException(error.toString());
|
|
|
|
|
|
|
|
|
|
_instructions.writeBytes(out);
|
|
|
|
|
|
|
|
|
|
if (_log.shouldLog(Log.DEBUG))
|
|
|
|
|
_log.debug("Wrote instructions: " + _instructions);
|
2005-02-16 jrandom
* (Merged the 0.5-pre branch back into CVS HEAD)
* Replaced the old tunnel routing crypto with the one specified in
router/doc/tunnel-alt.html, including updates to the web console to view
and tweak it.
* Provide the means for routers to reject tunnel requests with a wider
range of responses:
probabalistic rejection, due to approaching overload
transient rejection, due to temporary overload
bandwidth rejection, due to persistent bandwidth overload
critical rejection, due to general router fault (or imminent shutdown)
The different responses are factored into the profiles accordingly.
* Replaced the old I2CP tunnel related options (tunnels.depthInbound, etc)
with a series of new properties, relevent to the new tunnel routing code:
inbound.nickname (used on the console)
inbound.quantity (# of tunnels to use in any leaseSets)
inbound.backupQuantity (# of tunnels to keep in the ready)
inbound.length (# of remote peers in the tunnel)
inbound.lengthVariance (if > 0, permute the length by adding a random #
up to the variance. if < 0, permute the length
by adding or subtracting a random # up to the
variance)
outbound.* (same as the inbound, except for the, uh, outbound tunnels
in that client's pool)
There are other options, and more will be added later, but the above are
the most relevent ones.
* Replaced Jetty 4.2.21 with Jetty 5.1.2
* Compress all profile data on disk.
* Adjust the reseeding functionality to work even when the JVM's http proxy
is set.
* Enable a poor-man's interactive-flow in the streaming lib by choking the
max window size.
* Reduced the default streaming lib max message size to 16KB (though still
configurable by the user), also doubling the default maximum window
size.
* Replaced the RouterIdentity in a Lease with its SHA256 hash.
* Reduced the overall I2NP message checksum from a full 32 byte SHA256 to
the first byte of the SHA256.
* Added a new "netId" flag to let routers drop references to other routers
who we won't be able to talk to.
* Extended the timestamper to get a second (or third) opinion whenever it
wants to actually adjust the clock offset.
* Replaced that kludge of a timestamp I2NP message with a full blown
DateMessage.
* Substantial memory optimizations within the router and the SDK to reduce
GC churn. Client apps and the streaming libs have not been tuned,
however.
* More bugfixes thank you can shake a stick at.
2005-02-13 jrandom
* Updated jbigi source to handle 64bit CPUs. The bundled jbigi.jar still
only contains 32bit versions, so build your own, placing libjbigi.so in
your install dir if necessary. (thanks mule!)
* Added support for libjbigi-$os-athlon64 to NativeBigInteger and CPUID
(thanks spaetz!)
2005-02-16 22:23:47 +00:00
|
|
|
try {
|
|
|
|
|
byte m[] = _msg.toByteArray();
|
|
|
|
|
if (m == null)
|
|
|
|
|
throw new RuntimeException("foo, returned null");
|
|
|
|
|
if (m.length <= 0)
|
|
|
|
|
throw new RuntimeException("foo, returned 0 length");
|
|
|
|
|
out.write(m);
|
|
|
|
|
} catch (Exception e) {
|
|
|
|
|
throw new DataFormatException("Unable to write the clove: " + _msg + " to " + out, e);
|
|
|
|
|
}
|
2004-07-27 22:04:02 +00:00
|
|
|
DataHelper.writeLong(out, 4, _cloveId);
|
|
|
|
|
DataHelper.writeDate(out, _expiration);
|
|
|
|
|
if (_log.shouldLog(Log.DEBUG))
|
|
|
|
|
_log.debug("CloveID written: " + _cloveId + " expiration written: "
|
|
|
|
|
+ _expiration);
|
|
|
|
|
_certificate.writeBytes(out);
|
|
|
|
|
if (_log.shouldLog(Log.DEBUG))
|
|
|
|
|
_log.debug("Written cert: " + _certificate);
|
2004-04-08 04:41:54 +00:00
|
|
|
}
|
2005-07-31 21:35:26 +00:00
|
|
|
|
2009-04-21 03:32:38 +00:00
|
|
|
@Override
|
2005-07-31 21:35:26 +00:00
|
|
|
public byte[] toByteArray() {
|
|
|
|
|
byte rv[] = new byte[estimateSize()];
|
|
|
|
|
int offset = 0;
|
|
|
|
|
offset += _instructions.writeBytes(rv, offset);
|
|
|
|
|
if (_log.shouldLog(Log.DEBUG))
|
|
|
|
|
_log.debug("Wrote instructions: " + _instructions);
|
|
|
|
|
//offset += _msg.toByteArray(rv);
|
|
|
|
|
try {
|
|
|
|
|
byte m[] = _msg.toByteArray();
|
|
|
|
|
System.arraycopy(m, 0, rv, offset, m.length);
|
|
|
|
|
offset += m.length;
|
|
|
|
|
} catch (Exception e) { throw new RuntimeException("Unable to write: " + _msg + ": " + e.getMessage()); }
|
|
|
|
|
DataHelper.toLong(rv, offset, 4, _cloveId);
|
|
|
|
|
offset += 4;
|
|
|
|
|
DataHelper.toDate(rv, offset, _expiration.getTime());
|
|
|
|
|
offset += DataHelper.DATE_LENGTH;
|
|
|
|
|
offset += _certificate.writeBytes(rv, offset);
|
|
|
|
|
if (offset != rv.length)
|
|
|
|
|
_log.log(Log.CRIT, "Clove offset: " + offset + " but estimated length: " + rv.length);
|
|
|
|
|
return rv;
|
|
|
|
|
}
|
2004-04-08 04:41:54 +00:00
|
|
|
|
2005-02-16 jrandom
* (Merged the 0.5-pre branch back into CVS HEAD)
* Replaced the old tunnel routing crypto with the one specified in
router/doc/tunnel-alt.html, including updates to the web console to view
and tweak it.
* Provide the means for routers to reject tunnel requests with a wider
range of responses:
probabalistic rejection, due to approaching overload
transient rejection, due to temporary overload
bandwidth rejection, due to persistent bandwidth overload
critical rejection, due to general router fault (or imminent shutdown)
The different responses are factored into the profiles accordingly.
* Replaced the old I2CP tunnel related options (tunnels.depthInbound, etc)
with a series of new properties, relevent to the new tunnel routing code:
inbound.nickname (used on the console)
inbound.quantity (# of tunnels to use in any leaseSets)
inbound.backupQuantity (# of tunnels to keep in the ready)
inbound.length (# of remote peers in the tunnel)
inbound.lengthVariance (if > 0, permute the length by adding a random #
up to the variance. if < 0, permute the length
by adding or subtracting a random # up to the
variance)
outbound.* (same as the inbound, except for the, uh, outbound tunnels
in that client's pool)
There are other options, and more will be added later, but the above are
the most relevent ones.
* Replaced Jetty 4.2.21 with Jetty 5.1.2
* Compress all profile data on disk.
* Adjust the reseeding functionality to work even when the JVM's http proxy
is set.
* Enable a poor-man's interactive-flow in the streaming lib by choking the
max window size.
* Reduced the default streaming lib max message size to 16KB (though still
configurable by the user), also doubling the default maximum window
size.
* Replaced the RouterIdentity in a Lease with its SHA256 hash.
* Reduced the overall I2NP message checksum from a full 32 byte SHA256 to
the first byte of the SHA256.
* Added a new "netId" flag to let routers drop references to other routers
who we won't be able to talk to.
* Extended the timestamper to get a second (or third) opinion whenever it
wants to actually adjust the clock offset.
* Replaced that kludge of a timestamp I2NP message with a full blown
DateMessage.
* Substantial memory optimizations within the router and the SDK to reduce
GC churn. Client apps and the streaming libs have not been tuned,
however.
* More bugfixes thank you can shake a stick at.
2005-02-13 jrandom
* Updated jbigi source to handle 64bit CPUs. The bundled jbigi.jar still
only contains 32bit versions, so build your own, placing libjbigi.so in
your install dir if necessary. (thanks mule!)
* Added support for libjbigi-$os-athlon64 to NativeBigInteger and CPUID
(thanks spaetz!)
2005-02-16 22:23:47 +00:00
|
|
|
public int estimateSize() {
|
2005-07-31 21:35:26 +00:00
|
|
|
return _instructions.getSize()
|
2005-02-16 jrandom
* (Merged the 0.5-pre branch back into CVS HEAD)
* Replaced the old tunnel routing crypto with the one specified in
router/doc/tunnel-alt.html, including updates to the web console to view
and tweak it.
* Provide the means for routers to reject tunnel requests with a wider
range of responses:
probabalistic rejection, due to approaching overload
transient rejection, due to temporary overload
bandwidth rejection, due to persistent bandwidth overload
critical rejection, due to general router fault (or imminent shutdown)
The different responses are factored into the profiles accordingly.
* Replaced the old I2CP tunnel related options (tunnels.depthInbound, etc)
with a series of new properties, relevent to the new tunnel routing code:
inbound.nickname (used on the console)
inbound.quantity (# of tunnels to use in any leaseSets)
inbound.backupQuantity (# of tunnels to keep in the ready)
inbound.length (# of remote peers in the tunnel)
inbound.lengthVariance (if > 0, permute the length by adding a random #
up to the variance. if < 0, permute the length
by adding or subtracting a random # up to the
variance)
outbound.* (same as the inbound, except for the, uh, outbound tunnels
in that client's pool)
There are other options, and more will be added later, but the above are
the most relevent ones.
* Replaced Jetty 4.2.21 with Jetty 5.1.2
* Compress all profile data on disk.
* Adjust the reseeding functionality to work even when the JVM's http proxy
is set.
* Enable a poor-man's interactive-flow in the streaming lib by choking the
max window size.
* Reduced the default streaming lib max message size to 16KB (though still
configurable by the user), also doubling the default maximum window
size.
* Replaced the RouterIdentity in a Lease with its SHA256 hash.
* Reduced the overall I2NP message checksum from a full 32 byte SHA256 to
the first byte of the SHA256.
* Added a new "netId" flag to let routers drop references to other routers
who we won't be able to talk to.
* Extended the timestamper to get a second (or third) opinion whenever it
wants to actually adjust the clock offset.
* Replaced that kludge of a timestamp I2NP message with a full blown
DateMessage.
* Substantial memory optimizations within the router and the SDK to reduce
GC churn. Client apps and the streaming libs have not been tuned,
however.
* More bugfixes thank you can shake a stick at.
2005-02-13 jrandom
* Updated jbigi source to handle 64bit CPUs. The bundled jbigi.jar still
only contains 32bit versions, so build your own, placing libjbigi.so in
your install dir if necessary. (thanks mule!)
* Added support for libjbigi-$os-athlon64 to NativeBigInteger and CPUID
(thanks spaetz!)
2005-02-16 22:23:47 +00:00
|
|
|
+ _msg.getMessageSize()
|
|
|
|
|
+ 4 // cloveId
|
|
|
|
|
+ DataHelper.DATE_LENGTH
|
2005-07-31 21:35:26 +00:00
|
|
|
+ _certificate.size(); // certificate
|
2005-02-16 jrandom
* (Merged the 0.5-pre branch back into CVS HEAD)
* Replaced the old tunnel routing crypto with the one specified in
router/doc/tunnel-alt.html, including updates to the web console to view
and tweak it.
* Provide the means for routers to reject tunnel requests with a wider
range of responses:
probabalistic rejection, due to approaching overload
transient rejection, due to temporary overload
bandwidth rejection, due to persistent bandwidth overload
critical rejection, due to general router fault (or imminent shutdown)
The different responses are factored into the profiles accordingly.
* Replaced the old I2CP tunnel related options (tunnels.depthInbound, etc)
with a series of new properties, relevent to the new tunnel routing code:
inbound.nickname (used on the console)
inbound.quantity (# of tunnels to use in any leaseSets)
inbound.backupQuantity (# of tunnels to keep in the ready)
inbound.length (# of remote peers in the tunnel)
inbound.lengthVariance (if > 0, permute the length by adding a random #
up to the variance. if < 0, permute the length
by adding or subtracting a random # up to the
variance)
outbound.* (same as the inbound, except for the, uh, outbound tunnels
in that client's pool)
There are other options, and more will be added later, but the above are
the most relevent ones.
* Replaced Jetty 4.2.21 with Jetty 5.1.2
* Compress all profile data on disk.
* Adjust the reseeding functionality to work even when the JVM's http proxy
is set.
* Enable a poor-man's interactive-flow in the streaming lib by choking the
max window size.
* Reduced the default streaming lib max message size to 16KB (though still
configurable by the user), also doubling the default maximum window
size.
* Replaced the RouterIdentity in a Lease with its SHA256 hash.
* Reduced the overall I2NP message checksum from a full 32 byte SHA256 to
the first byte of the SHA256.
* Added a new "netId" flag to let routers drop references to other routers
who we won't be able to talk to.
* Extended the timestamper to get a second (or third) opinion whenever it
wants to actually adjust the clock offset.
* Replaced that kludge of a timestamp I2NP message with a full blown
DateMessage.
* Substantial memory optimizations within the router and the SDK to reduce
GC churn. Client apps and the streaming libs have not been tuned,
however.
* More bugfixes thank you can shake a stick at.
2005-02-13 jrandom
* Updated jbigi source to handle 64bit CPUs. The bundled jbigi.jar still
only contains 32bit versions, so build your own, placing libjbigi.so in
your install dir if necessary. (thanks mule!)
* Added support for libjbigi-$os-athlon64 to NativeBigInteger and CPUID
(thanks spaetz!)
2005-02-16 22:23:47 +00:00
|
|
|
}
|
|
|
|
|
|
2009-04-21 03:32:38 +00:00
|
|
|
@Override
|
2004-04-08 04:41:54 +00:00
|
|
|
public boolean equals(Object obj) {
|
|
|
|
|
if ( (obj == null) || !(obj instanceof GarlicClove))
|
|
|
|
|
return false;
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
GarlicClove clove = (GarlicClove)obj;
|
|
|
|
|
return DataHelper.eq(getCertificate(), clove.getCertificate()) &&
|
2004-07-27 22:04:02 +00:00
|
|
|
DataHelper.eq(getCloveId(), clove.getCloveId()) &&
|
|
|
|
|
DataHelper.eq(getData(), clove.getData()) &&
|
|
|
|
|
DataHelper.eq(getExpiration(), clove.getExpiration()) &&
|
|
|
|
|
DataHelper.eq(getInstructions(), clove.getInstructions());
|
2004-04-08 04:41:54 +00:00
|
|
|
}
|
|
|
|
|
|
2009-04-21 03:32:38 +00:00
|
|
|
@Override
|
2004-04-08 04:41:54 +00:00
|
|
|
public int hashCode() {
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
return DataHelper.hashCode(getCertificate()) +
|
2004-07-27 22:04:02 +00:00
|
|
|
(int)getCloveId() +
|
|
|
|
|
DataHelper.hashCode(getData()) +
|
|
|
|
|
DataHelper.hashCode(getExpiration()) +
|
|
|
|
|
DataHelper.hashCode(getInstructions());
|
2004-04-08 04:41:54 +00:00
|
|
|
}
|
|
|
|
|
|
2009-04-21 03:32:38 +00:00
|
|
|
@Override
|
2004-04-08 04:41:54 +00:00
|
|
|
public String toString() {
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
StringBuffer buf = new StringBuffer(128);
|
2004-04-08 04:41:54 +00:00
|
|
|
buf.append("[GarlicClove: ");
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
buf.append("\n\tInstructions: ").append(getInstructions());
|
|
|
|
|
buf.append("\n\tCertificate: ").append(getCertificate());
|
|
|
|
|
buf.append("\n\tClove ID: ").append(getCloveId());
|
|
|
|
|
buf.append("\n\tExpiration: ").append(getExpiration());
|
|
|
|
|
buf.append("\n\tData: ").append(getData());
|
|
|
|
|
buf.append("]");
|
|
|
|
|
return buf.toString();
|
2004-04-08 04:41:54 +00:00
|
|
|
}
|
|
|
|
|
}
|