xlattice-devel Mailing List for The XLattice Project
Status: Beta
Brought to you by:
jddixon
Menu
▾
▴
xlattice-devel — For XLattice developers
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
(1) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(2) |
Aug
(5) |
Sep
(2) |
Oct
|
Nov
(1) |
Dec
(1) |
| 2005 |
Jan
(2) |
Feb
(2) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2006 |
Jan
|
Feb
(7) |
Mar
(8) |
Apr
(11) |
May
(9) |
Jun
(5) |
Jul
(3) |
Aug
|
Sep
|
Oct
(13) |
Nov
|
Dec
|
|
From: Emi <em...@gm...> - 2006-10-04 04:45:04
|
Hi, I am looking into the crypto package and am trying to understand a couple of things about the bloom filter implementation. I am a little bit confused on why there is the restriction on the size of the bloom filter 2^m with m ranging btw 2..20 only and also the number of hashing functions k to range btw 1..8 only. With this current setup for the maximum allowed values the bloom filter can accommodate for an optimum error positive rate 90852 keys in the bloom filter only: 8 = 2^20 / 90852 *ln2 Can the values for k and m be bigger? Right now, in the code it does not accept bigger values than the ones I specified before. How can the bloom filter accommodate a large number of keys with low error rate if m can only go up to 20? This limits the number of keys to 2^20. What is I need to bloom filter more than 10^6 keys? Are these 2 restrictions on k and m due to the hash functions implementation in class KeySelector? If yes can you please let me know a bloom filter solution that accepts any values for k and m so that it can accommodate any number of keys for any error rate? Also, the code in the KeySelector class that generates for a given key the k hash values is not very documented. I do not understand how the hash functions are computed on the input key. More exactly, what is the strategy of selecting the set of *distinct* bits from the key for each hash function to generate its hash value. I'd appreciate any help or more comments on this section too. Thanks! -- .uci |
|
From: Jim D. <jd...@di...> - 2006-07-10 16:44:44
|
We add NameGenerator to corexml.bind. This is a facility for generating class, method, and variable names in a standardized way. These names are to be used in various types of automatically generated code, as for example in other bind methods; in XLattice's ProjMgr component; and in the forthcoming JAppGen J2EE MVC application generator project, jappgen.sourceforge.net. -- Jim Dixon jd...@di... tel +44 117 982 0786 mobile +44 797 373 7881 http://xlattice.sourceforge.net p2p communications infrastructure |
|
From: Jim D. <jd...@di...> - 2006-07-10 14:19:04
|
This release adds ucFirst and lcFirst methods to StringLib. These are used fairly heavily by upcoming corexml and projmgr component releases, which are used by the JAppGen J2EE MVC application generator, jappgen.sourceforge.net. -- Jim Dixon jd...@di... tel +44 117 982 0786 mobile +44 797 373 7881 http://xlattice.sourceforge.net p2p communications infrastructure |
|
From: Jim D. <jd...@di...> - 2006-07-07 16:38:46
|
ProjMgr has been missing from CVS due to an oversight. It was imported into CVS yesterday. Significant improvements are being implemented at the moment and should result in a 0.4.1 release within the week -- Jim Dixon jd...@di... tel +44 117 982 0786 mobile +44 797 373 7881 http://xlattice.sourceforge.net p2p communications infrastructure |
|
From: Jim D. <jd...@di...> - 2006-06-21 15:54:22
|
This is a minor release. context/ has been moved to the util component, and necessary changes in code have been made. We switch to using junit-4.1 for testing, in line with the earlier switch to Java 1.5. As usual, we include source code for this component and jars for all dependencies. -- Jim Dixon jd...@di... tel +44 117 982 0786 mobile +44 797 373 7881 http://xlattice.sourceforge.net p2p communications infrastructure |
|
From: Jim D. <jd...@di...> - 2006-06-21 15:38:03
|
ProjMgr's first update in a couple of years sees util/context/ replacing corexml/context/, JUnit updated to 4.1, and the use of Java 1.5. We also relax restrictions on version numbers; any JNLP version number is now acceptable. Finally, a number of minor bugs have been fixed. This is a clean-up preparatory to using ProjMgr in the soon-to-be released JAppGen project. As usual, the .ZIP file includes source code for this component (ProjMgr) and jars for all dependencies. -- Jim Dixon jd...@di... tel +44 117 982 0786 mobile +44 797 373 7881 http://xlattice.sourceforge.net p2p communications infrastructure |
|
From: Jim D. <jd...@di...> - 2006-06-19 16:36:22
|
v0.3.8 makes minor changes to fundamental XLattice classes, including Transport, Peer, and NodeID. We switch to using JUnit 4.1 for unit testing. The release is now packaged as a ZIP file instead of a UNIX tarball. -- Jim Dixon jd...@di... tel +44 117 982 0786 mobile +44 797 373 7881 http://xlattice.sourceforge.net p2p communications infrastructure |
|
From: Jim D. <jd...@di...> - 2006-06-15 18:18:16
|
This release adds TLS contexts and sessions which considerably reduce the effort required to implement peer-to-peer TLS connections between XLattice Nodes as well as SSL connections between XLattice-based HTTP clients and servers. -- Jim Dixon jd...@di... tel +44 117 982 0786 mobile +44 797 373 7881 http://xlattice.sourceforge.net p2p communications infrastructure |
|
From: Jim D. <jd...@di...> - 2006-06-04 17:40:22
|
This release improves the implementation of SignedLists and adds the TLSEngine which will be used as the basis for most node-to-node communications in XLattice networks. This is our first release using features of Java 1.5 -- Jim Dixon jd...@di... tel +44 117 982 0786 mobile +44 797 373 7881 http://xlattice.sourceforge.net p2p communications infrastructure |
|
From: Jim D. <jd...@di...> - 2006-05-24 17:20:10
|
This is the first release of XLattice's node component. A node is the key building block in our approach to peer-to-peer networking. A node has a cryptographic identity (an RSA key and a 160-bit SHA1-derived node ID) and can communicate with other nodes through one or more overlays. An overlay is a combination of a transport, a protocol, and an address space. Nodes from this first release communicate using TLS/SSL and UDP. -- Jim Dixon jd...@di... tel +44 117 982 0786 mobile +44 797 373 7881 http://xlattice.sourceforge.net p2p communications infrastructure |
|
From: Jim D. <jd...@di...> - 2006-05-21 18:03:49
|
Released today on Sourceforge. This adds both blocking and non-blocking UDP to the transport compoenent. We will bump the version number to 0.1.2 in CVS, but higher-level components will continue to use transport-0.1.1 for awhile, at least until the node-0.1.0 release, due out within the week. -- Jim Dixon jd...@di... tel +44 117 982 0786 mobile +44 797 373 7881 http://xlattice.sourceforge.net p2p communications infrastructure |
|
From: Jim D. <jd...@di...> - 2006-05-15 13:35:32
|
On Mon, 15 May 2006, Jim Dixon wrote: > After bringing most XLattice components in sync with Sourceforge CVS, > while attempting to commit the second to last (cpp) I get: > > ------------------------------------------------------------------------ > ssh: connect to host cvs.sf.net port 22: Connection refused > cvs [commit aborted]: end of file from server (consult above messages if > any) > ------------------------------------------------------------------------ > > I have tried the commit several times with the same results. :-( This turns out to have been due to apparent corruption in the CVS - there is a hint in the first error line, which should have referred to xlattice.cvs.sf.net. I checked out the cpp component again, hand-edited the util/CVS/Entries file, and now have successfully committed cpp, httpd, and cryptoserver. That is, CVS at Sourceforge appears to be OK -- although the apparent corruption is worrying. -- Jim Dixon jd...@di... tel +44 117 982 0786 mobile +44 797 373 7881 http://xlattice.sourceforge.net p2p communications infrastructure |
|
From: Jim D. <jd...@di...> - 2006-05-15 09:14:32
|
After bringing most XLattice components in sync with Sourceforge CVS, while attempting to commit the second to last (cpp) I get: ------------------------------------------------------------------------ ssh: connect to host cvs.sf.net port 22: Connection refused cvs [commit aborted]: end of file from server (consult above messages if any) ------------------------------------------------------------------------ I have tried the commit several times with the same results. :-( -- Jim Dixon jd...@di... tel +44 117 982 0786 mobile +44 797 373 7881 http://xlattice.sourceforge.net p2p communications infrastructure |
|
From: Jim D. <jd...@di...> - 2006-05-11 08:31:24
|
Previously CVS was down - and due to be fixed yesterday. The situation now: ------------------------------------------------------------------------ ssh: cvs.sf.net: Temporary failure in name resolution cvs [commit aborted]: end of file from server (consult above messages if any) ------------------------------------------------------------------------ cvs.sourceforge.net has been removed from the DNS. -- Jim Dixon jd...@di... tel +44 117 982 0786 mobile +44 797 373 7881 http://xlattice.sourceforge.net p2p communications infrastructure |
|
From: Jim D. <jd...@di...> - 2006-05-10 14:38:21
|
"2006-05-10 04:43:14 - Project CVS Service ) As of 2006-05-09 the developer CVS server had a disk-failure. As the new CVS infrastructure is in its final phases of rollout, we'll be deploying it, in place of the current infrastructure, by end of week. We'll be sending out an email to project administrators with further details later in the day, regarding how to access the new CVS servers and the changes that occurred with the new infrastructure." -- Jim Dixon jd...@di... tel +44 117 982 0786 mobile +44 797 373 7881 http://xlattice.sourceforge.net p2p communications infrastructure |
|
From: Jim D. <jd...@di...> - 2006-05-05 14:27:19
|
This release fixes a critical fault in the STUN server. As usual, there are three files: protocol-0.1.6, stunplus-0.1.6, and stunplus-current. The first is the source release, the second the binary-only release, and the third is identical to the second. -- Jim Dixon jd...@di... tel +44 117 982 0786 mobile +44 797 373 7881 http://xlattice.sourceforge.net p2p communications infrastructure |
|
From: Jim D. <jd...@di...> - 2006-05-04 22:12:55
|
This is version 0.1.5 of the STUN+/protocol package. It corrects bugs reported and makes most enhancements requested through the Sourceforge tracker. It also adds the first elements of the XLattice messaging protocol. The GUI client now supports encrypted authentication using TLS/TCP. It also allows users to select most of the standard STUN servers through a pulldown menu. We would appreciate any further suggestions for GUI client enhancements after user experience with the package. As usual, there are three files in the release: protocol-0.1.5.zip, stunplus-0.1.5.zip, and stunplus-current.zip. The first is the source release. The second is a binary release with command files (.sh, .bat) for the STUN server, command-line client, and GUI client. The third is identical to the second. -- Jim Dixon jd...@di... tel +44 117 982 0786 mobile +44 797 373 7881 http://xlattice.sourceforge.net p2p communications infrastructure |
|
From: Jim D. <jd...@di...> - 2006-05-02 08:13:30
|
If I browse Sourceforge CVS, I find that changes commited to CVS early in April are not there. It appears to be a snapshot of CVS taken about six weeks ago. Given these circumstances, it seems sensible to start making weekly releases for any components actively in development. We'll start with the C++ component, cpp. -- Jim Dixon jd...@di... tel +44 117 982 0786 mobile +44 797 373 7881 http://xlattice.sourceforge.net p2p communications infrastructure |
|
From: Jim D. <jd...@di...> - 2006-04-28 22:26:40
|
cvs add Buffer.cpp core.h nextbuild.C ssh: connect to host cvs.sf.net port 22: Connection timed out cvs [add aborted]: end of file from server (consult above messages if any) Significant progress is being made on the C++ side, but I can't get it into Sourceforge CVS. -- Jim Dixon jd...@di... tel +44 117 982 0786 mobile +44 797 373 7881 http://xlattice.sourceforge.net p2p communications infrastructure |
|
From: Jim D. <jd...@di...> - 2006-04-25 15:16:38
|
I have begun working on the XLattice C++ code and would appreciate feedback on the approach planned. The C++ code is in the cpp component and so found under $XLATTICE_HOME/cpp. This more or less mirrors the structure of the Java code. The major difference is that much of the functionity now in the Java xlattice/util component is in xlattice/cpp/core. However, some of this may wind up in xlattice/cpp/util. The reason for the change in approach is that in the Java code the basic XLattice abstractions are collected in the util component's src/java/org/xlattice directory, with actual utility code one directory below that, in src/java/org/xlattice/util and subdirectories. This is a bit confusing. In all other cases, all non-test code for the component is under src/java/org/xlattice/$COMPONENT_NAME DIRECTORY STRUCTURE * There are 6 [8] component directories below xlattice/cpp - core, [util, corexml,] crypto, transport, protocol, overlay, node, where those in square brackets are currently absent. In addition there are include/ and lib/ direcories at the same level, and a perl/ directory, about which more later. * Each component directory has src/, test/, and build/ subdirectories. These may have sub-subdirectories. There are C++ source files in src/ and test/. These are compiled to build/. Compiled code from src/ goes into the library for the component and any deliverable executables. Compiled code and executables from test/ goes into build/ but not into the component library. * In each component directory there is a Makefile. This is generated by a Perl script, perl/makemake.pl. These are not recursive Makefiles. Each includes body.mk from the topmost component directory. Each component is assumed to depend upon the library from the next-lower component. Transport, for example, depends upon crypto which in turn depends upon core. Therefore each body.mk includes body.mk from the earlier component. The result is that invoking make in cpp/transport will result in as many lower-level libraries being rebuilt as necessary, but does not affect anything in higher level components. * This is not yet implemented, but the intention is that the Makefile should automatically run unit tests and only build the component library if the tests succeed. That is, the Makefile should have much the same targets as XLattice's Ant build.xml. * cppunit doesn't seem appropriate, so the plan is to do a compatible xunit implementation, tentatively called cpptest. FUNCTIONALITY This is largely a discussion of what goes into the cpp/core component. As I see it now, at least the following should be part of the component: * cpptest, the unit test package * a simple garbage collection scheme built around reference-counting objects * immutable Strings, as familiar from Java; these may not be guaranteed to be unique * StringBuffers, as from Java * callbacks, as in the CryptoServer * an events package The objective is to be able to build single-threaded XLattice nodes. In order to be single-threaded, these have to be organized around events: when code would otherwise block, it registers a callback to handle the pending event. Whenever it would go idle, it checks for ready events and handles them using the registered callbacks. Because in an event-oriented environment it is difficult to track when objects can be disposed, we need some sort of automatic garbage collection. Necessarily this involves reference counting. Many, possibly most, of the objects that need reference counting will be Strings. Experience with Java shows that where you have immutable Strings subject to GC, you also need StringBuffers, to efficiently build the Strings and to avoid polluting the world with immutable String fragments. Finally, all of this is going to be very complicated and error-prone, so we need the basic tools required for test-driven development: cpptest and friends. Also part of cpp/core will be basic XLattice abstractions: Acceptor, Connector, Connection, and Transport; DigSigner, Key, PublicKey, Secret, and SigVerifier; Node and Peer. It is very likely that the crypto stuff will just be a wrapper around crypto packages, most obviously OpenSSL. Tentatively we will try to make this look like Sun's JCE, where different providers can be plugged into a common interface. Any feedback on the above would be very much appreciated. -- Jim Dixon jd...@di... tel +44 117 982 0786 mobile +44 797 373 7881 http://xlattice.sourceforge.net p2p communications infrastructure |
|
From: Jim D. <jd...@di...> - 2006-04-25 11:50:56
|
The 0.1.4 protocol release adds a GUI client and corrects all of the more serious limitations reported through the Sourceforge tracker. We add a facility for testing binding lifetime, but this has not been thoroughly tested. The GUI client should run on any host with a reasonably recent version of Java. We would appreciate feedback from users. Server discovery is supported in this release but limited to UDP servers in the GUI client. The command line client supports encrypted authentication using TLS. The GUI client as yet doesn't. As usual, there are three files in the release: protocol-0.1.4.zip, stunplus-0.1.4.zip, and stunplus-current.zip. -- Jim Dixon jd...@di... tel +44 117 982 0786 mobile +44 797 373 7881 http://xlattice.sourceforge.net p2p communications infrastructure |
|
From: Jim D. <jd...@di...> - 2006-04-20 21:13:16
|
On Thu, 20 Apr 2006 fox...@xl... wrote:
> if you click on the little ball about one-third down the sf project
> screen on the right hand side, it has all sorts of announcements,
> including many about vcs . apparently while anonymous cvs is down,
> developercvs is up, but possibly corrupt. they are replacing hardware,
> expect things to be back up real soon now.
>
> /fox
Perhaps in theory developer CVS is up - but in practice it's down.
I just tried to add Mark's GUI client to CVS and got:
{883} cvs add stun.gui.*
ssh: connect to host cvs.sf.net port 22: Connection refused
cvs [add aborted]: end of file from server (consult above messages if any)
--
Jim Dixon jd...@di... tel +44 117 982 0786 mobile +44 797 373 7881
http://xlattice.sourceforge.net p2p communications infrastructure
|
|
From: <fox...@xl...> - 2006-04-20 18:12:54
|
if you click on the little ball about one-third down the sf project screen on the right hand side, it has all sorts of announcements, including many about vcs . apparently while anonymous cvs is down, developercvs is up, but possibly corrupt. they are replacing hardware, expect things to be back up real soon now. /fox |
|
From: Jim D. <jd...@di...> - 2006-04-15 14:54:17
|
Because Sourceforge CVS is lagging by a couple of weeks, I put the following releases on Sourceforge: * util-0.3.7.tar.gz * corexml-0.3.3.tar.gz * crypto-0.1.0.zip * transport-0.1.0.zip The next protocol/stunplus release will be out shortly, probably today or tomorrow. The util and corexml components are being released as tar.gz simply due to the pressure of time. The next releases will be packaged as zip files, for greater convenience for Windows users. All of this code has been tested on Windows XP as well as on Debian Linux. -- Jim Dixon jd...@di... tel +44 117 982 0786 mobile +44 797 373 7881 http://xlattice.sourceforge.net p2p communications infrastructure |
|
From: Jim D. <jd...@di...> - 2006-04-13 15:55:47
|
In a spot-check on XLattice CVS on Sourceforge the most recent updates are dated about two weeks ago, although we made commits yesterday. In consequence, CVS checkouts are not consistent with the recent STUN releases. Therefore the next protocol/stun+ release, which will probably be tomorrow, will be accompanied by simultaneous releases of current component tarballs for util, corexml, crypto, and transport. All of these will include working *.bat files resulting from Mark's tests on Windows XP. The first C++ code should also be released this weekend. -- Jim Dixon jd...@di... tel +44 117 982 0786 mobile +44 797 373 7881 http://xlattice.sourceforge.net p2p communications infrastructure |
15 messages has been excluded from this view by a project administrator.
