Also, does Fred check for reserved address ranges? It seems this would
be able to rule out most publicly inaccessible interfaces.
Scott
On Tue, May 27, 2003 at 10:32:25PM +0200, Niklas Bergh wrote:
> This is from the fascinating world of Microsoft..
>
> I was very surprised to notice
Do you guys have any profiling data to suggest this is beneficial? At
last check, the Java crypto was not a substantial performance problem,
and we found that these problems only arose under heavy load because of
context-switch cache flushing. If this is the case, native crypto isn't
going
On Wed, May 21, 2003 at 04:02:31AM +0100, Toad wrote:
> On Wed, May 21, 2003 at 03:25:07AM +0100, Toad wrote:
> > D'OH.
> >
> > java.security.MessageDigest, not javax.crypto.Mac.
>
> Okay, that IS compatible. And about 7MB/sec on my system against about
> 3MB/sec for our java code on the same
On Wed, May 21, 2003 at 03:25:07AM +0100, Toad wrote:
> D'OH.
>
> java.security.MessageDigest, not javax.crypto.Mac.
A message digest is a hash function. A Mac is a Message Authentication
Code, which is usually a keyed digest. A MAC requires the key to be
verified correctly. This is used
On Mon, Mar 31, 2003 at 12:09:44AM -0500, Zlatin Balevsky wrote:
> well, I discovered two huge bugs in the java.nio package. The first one
> I mailed to Matthew and it is that the read() reads bytes as signed
> octets even though in the javadocs it explicitly says the values
>
Has any of the work cited here been incorporated into Fred?
http://www.lclark.edu/~ppair/mache.pdf
Scott
--
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
On Mon, Mar 17, 2003 at 11:07:00AM -0800, Ian Clarke wrote:
> > Anyway I'd like that only audio/video streaming content does
> > hara-kiri and not the "normal freesites content". But I think
> > there would be no secure way to distinguish them.
>
> There is no need to "distinguish" them, it will
On Thu, Mar 13, 2003 at 09:54:44PM -0700, Nathan Johnson wrote:
> I e-mailed you about how to report bugs to freenet project when the web site
> was linking to sourceforge. You gold me that sourceforge isn't used for
> freenet bug tracking. I'm looking at front page for freenet project now and
>
On Thu, Mar 13, 2003 at 06:31:24PM +, Timm Murray wrote:
> > On Wed, Mar 12, 2003 at 06:32:04PM -0800, Ian Clarke wrote:
> > > > Doing this ourselves is a waste of time. We'd be better off with a
> > > > second-generation IP protocol like SCTP or RUDP. The former is a TCP
> > > >
On Tue, Jan 28, 2003 at 06:41:30PM -0800, Ian Clarke wrote:
> I am curious as to why only a percentage of the missing data blocks are
> healed (the default being a very small percentage)?
I'm not the author, but if I were to guess I'd say to prevent a huge
insert load from being foisted onto a
On Sat, Jan 18, 2003 at 04:50:37PM -0500, Gianni Johansson wrote:
> I am beginning to think that using CHKs for SplitFile checksums isn't a good
> idea.
>
> If we use something that is widely deployed like MD5, then SplitFile client
> authors can check the checksum themselves using their
On Fri, Sep 06, 2002 at 08:44:08AM -0700, Ian Clarke wrote:
> On Fri, Sep 06, 2002 at 12:06:16PM +0100, Matthew Toseland wrote:
> > > This could easily be the problem as I know that Matthew recently made
> > > some modifications to the announcement code.
> > Yup. Build 500 had a combinatorial
>
> I'm unclear on just why a Java VM would get this. It seems that they
> (most of them) pre-allocate a large chunk of memory (64 MB), and then
> dole this out to the application as it's needed. But what happens
> when that initial chunk is all used up? Doesn't it allocate more?
> Perhaps,
13 matches
Mail list logo