Re: GMP upgrade?

On 30-Jul-2005 Matthew Toseland wrote:
> Not me.
> 
> On Mon, Jul 25, 2005 at 09:57:06PM -0500, Conrad J. Sabatier wrote:
>> Would anyone have any objection to upgrading the version of gmp used
>> in
>> Contrib/NativeBigInteger to the latest version (4.1.4)?  I don't
>> think
>> it should cause any problems.
>> 
>> Here are the changes listed on the web site:
>> 
>> Changes between GMP version 4.1.3 and 4.1.4
>> 
>>     * Bug fix to FFT multiplication code (crash for huge operands).
>>     * Bug fix to mpf_sub (miscomputation).
>>     * Support for powerpc64-gnu-linux.
>>     * Better support for AMD64 in 32-bit mode.
>>     * Upwardly binary compatible with 4.1.3, 4.1.2, 4.1.1, 4.1,
>>     4.0.1,
>>       4.0, and 3.x versions. 
>> 
>> I think we should go for it, myself.  
> 
> Sounds good to me. Then you can build a k8shortmode .so :)

Yes, I think I need to rethink my approach to building a library for
64-bit platforms, as the current method clearly isn't working.

Re: A thorny problem for 64-bit jbigi

On 30-Jul-2005 Matthew Toseland wrote:
> Have you tried talking to the libgmp people?

No, I haven't, not yet.  I need to collect some more info to forward on
to them, so they can get a clear understanding of what the problem is.

> On Mon, Jul 25, 2005 at 09:52:51PM -0500, Conrad J. Sabatier wrote:
>> I'm really not sure how to resolve the following issue on the amd64
>> platform.
>> 
>> In jbigi.c, at line 162, in function void convert_mp2j, the second
>> argument (&size) to mpz_export is declared as being of type jsize,
>> which
>> Sun's JDK defines to be of type jint on this platform, which in turn
>> translates into the standard definition of int on this architecture
>> (32
>> bits).  However, pointers on the amd64 are 64 bits.  So, of course,
>> the
>> compiler warns about an incompatible pointer type, and of course,
>> the
>> library, crashes on startup right at this point.
>> 
>> Any ideas how to work around this?  Would it be permissible to use a
>> long here instead?  Or will this just cause another problem
>> somewhere
>> else?
>> 
>> Just for reference, here's the output of a little C program I wrote
>> to

Re: A thorny problem for 64-bit jbigi

On 30-Jul-2005 Matthew Toseland wrote:
> Oh and what the hell is a long double?

It's just a double that's twice as wide as the regular double. 
Probably not even something we need to concern ourselves with as far as
the gmp/libjbigi stuff.  I just included it in the output of my
"sizeof" program purely for informational purposes.

I'm wondering if a simple cast for the &size argument might do the
trick.  I'll have to to some further testing on this.

> On Mon, Jul 25, 2005 at 09:52:51PM -0500, Conrad J. Sabatier wrote:
>> I'm really not sure how to resolve the following issue on the amd64
>> platform.
>> 
>> In jbigi.c, at line 162, in function void convert_mp2j, the second
>> argument (&size) to mpz_export is declared as being of type jsize,
>> which
>> Sun's JDK defines to be of type jint on this platform, which in turn
>> translates into the standard definition of int on this architecture
>> (32
>> bits).  However, pointers on the amd64 are 64 bits.  So, of course,
>> the
>> compiler warns about an incompatible pointer type, and of course,
>> the
>> library, crashes on startup right at this point.
>> 
>> Any ideas how to work around this?  Would it be permissible to use a
>> long here instead?  Or will this just cause another problem

RE: A thorny problem for 64-bit jbigi

I think you should probably define size as int instead of as an jint. The
mpz_sizeinbase and the mpz_export functions doesn't really have anything at
all to do with java.. They are just methods for converting a GMP biginteger
to another int format.. And the size param is there only for passing info
between those two.

Regards
/N

> -----Original Message-----
> From: devl-bounces@... 
> [mailto:devl-bounces@...] On Behalf Of Conrad 
> J. Sabatier
> Sent: den 1 augusti 2005 03:44
> To: Matthew Toseland
> Cc: Discussion of development issues
> Subject: Re: [freenet-dev] A thorny problem for 64-bit jbigi
> 
> 
> 
> On 30-Jul-2005 Matthew Toseland wrote:
> > Oh and what the hell is a long double?
> 
> It's just a double that's twice as wide as the regular double. 
> Probably not even something we need to concern ourselves with 
> as far as the gmp/libjbigi stuff.  I just included it in the 
> output of my "sizeof" program purely for informational purposes.
> 
> I'm wondering if a simple cast for the &size argument might 
> do the trick.  I'll have to to some further testing on this.

Re: report

So we should add extra complexity specifically to gloss over known
bugs?!

On Sun, Jul 31, 2005 at 11:35:35AM -0700, Ian Clarke wrote:
> If we are routinely ignoring a bug report then we should make this  
> clear to users so that they don't waste their time reporting bugs.  I  
> think that is only fair to our users.
> 
> Ian.
> 
> On 30 Jul 2005, at 06:17, Matthew Toseland wrote:
> 
> >The reason I don't add code to fproxy to ignore this bug and turn it
> >into a transfer failure is that I don't think that adding code to  
> >ignore
> >bugs is a good idea!
> >
> >On Sat, Jul 30, 2005 at 02:14:43PM +0100, Matthew Toseland wrote:
> >
> >>Thanks for reporting this bug. It is a well known bug in how a  
> >>transfer
> >>failure is reported. We are not working on it at the moment.
> >>
> >>On Wed, Jul 27, 2005 at 02:28:46PM +0200, Egbert van der Meer wrote:
> >>
> >>>
> >>>
> >>>freenet.client.WrongStateException: Wrong state: FAILED should be  
> >>>DONE:
> >>>null: Transfer failed with 91478 moved.

Re: report

We should not waste our user's time by encouraging them to report  
bugs that we have no intention of fixing.

Ian.

On 1 Aug 2005, at 06:05, Matthew Toseland wrote:

> So we should add extra complexity specifically to gloss over known
> bugs?!
>
> On Sun, Jul 31, 2005 at 11:35:35AM -0700, Ian Clarke wrote:
>
>> If we are routinely ignoring a bug report then we should make this
>> clear to users so that they don't waste their time reporting bugs.  I
>> think that is only fair to our users.
>>
>> Ian.
>>
>> On 30 Jul 2005, at 06:17, Matthew Toseland wrote:
>>
>>
>>> The reason I don't add code to fproxy to ignore this bug and turn it
>>> into a transfer failure is that I don't think that adding code to
>>> ignore
>>> bugs is a good idea!
>>>
>>> On Sat, Jul 30, 2005 at 02:14:43PM +0100, Matthew Toseland wrote:
>>>
>>>
>>>> Thanks for reporting this bug. It is a well known bug in how a

Re: How to establish new connections

On Mon, Aug 01, 2005 at 01:28:48PM -0700, Ian Clarke wrote:
> Of critical importance to the success of the "darknet" feature of  
> Freenet 0.7 is that it is extremely easy for Freenet users to  
> establish new connections with each-other.
> 
> If both peers are behind NATs then, at the very least, they will need  
> to exchange their external IP addresses and port numbers.  They will  
> also want to exchange a token-key of some kind too to indicate that  
> they have permission to connect (I think toad is calling this the  
> "identity").

The problem with this is that their IP addresses are likely to change
from time to time. If they are unlucky or have extended downtime, all
their hosts will be unreachable. In which case they will have to get the
IP of at least one by hand. Once they have one they can contact the
others through the network. Reliable node-to-node messaging is really
useful. :)
> 
> If one peer is behind a NAT but the other isn't then it will need the  
> IP address and port of the other, and perhaps some kind of token as  
> above, but the other can just listen for the connection.  The same is  
> true if neither peers are behind NATs.

Yup. We can then connect by identity, by something like the protocol we
use in 0.5. Which can have silent bob i.e. not be portscannable.
> 
> So, how can this information be exchanged conveniently?  Email is an  
> obvious choice, but may mean that several hours pass between each  
> peer trying to connect to the other. 

Re: How to establish new connections

Matthew Toseland <toad <at> ...> writes:

--snip--
> A simple string perhaps; simply the IP address in its usual textual
> form. If the usual means of exchange would be via email etc, then
> embedding it in a URL would be reasonable:
> http://127.0.0.1/updateNode?id=0x43522561&ip=212.67.81.5

How do we address filters that look for freenet-invite emails? It seems like
this would be the easiest way to harvest darknets : sending IP is probably a
freenet node, destination IP goes on a list of potential dissidents that may run
it soon, AND they know there's a trust relationship between them. Encryption +
steganography looks like the only halfway safe method of doing this IMO, and
that's not exactly convenient ... have I missed something (again)?

Bob

Re: Re: How to establish new connections

On Tue, Aug 02, 2005 at 03:22:14PM +0000, Bob wrote:
> Matthew Toseland <toad <at> ...> writes:
> 
> --snip--
> > A simple string perhaps; simply the IP address in its usual textual
> > form. If the usual means of exchange would be via email etc, then
> > embedding it in a URL would be reasonable:
> > http://127.0.0.1/updateNode?id=0x43522561&ip=212.67.81.5
> 
> How do we address filters that look for freenet-invite emails? It seems like
> this would be the easiest way to harvest darknets : sending IP is probably a
> freenet node, destination IP goes on a list of potential dissidents that may run
> it soon, AND they know there's a trust relationship between them. Encryption +
> steganography looks like the only halfway safe method of doing this IMO, and
> that's not exactly convenient ... have I missed something (again)?

Well, the more hostile the environment, the less convenient things are
likely to get... and with long-term data retention on the cards even in
the West, such things aren't very safe... The above isn't an invite,
it's actually an update...
> 
> Bob
--

-- 
Matthew J Toseland - toad@...
Freenet Project Official Codemonkey - http://freenetproject.org/
ICTHUS - Nothing is impossible. Our Boss says so.

_______________________________________________
Devl mailing list

Re: Re: How to establish new connections

In the long term the only really viable answer is "don't send invites
over the internet". :( In the short term, encrypted emails will be fine.
Given moves to retain emails for a year in the EU, it would be highly
recommended to encrypt invites... (and everything else :) )...

On Tue, Aug 02, 2005 at 03:22:14PM +0000, Bob wrote:
> Matthew Toseland <toad <at> ...> writes:
> 
> --snip--
> > A simple string perhaps; simply the IP address in its usual textual
> > form. If the usual means of exchange would be via email etc, then
> > embedding it in a URL would be reasonable:
> > http://127.0.0.1/updateNode?id=0x43522561&ip=212.67.81.5
> 
> How do we address filters that look for freenet-invite emails? It seems like
> this would be the easiest way to harvest darknets : sending IP is probably a
> freenet node, destination IP goes on a list of potential dissidents that may run
> it soon, AND they know there's a trust relationship between them. Encryption +
> steganography looks like the only halfway safe method of doing this IMO, and
> that's not exactly convenient ... have I missed something (again)?
> 
> Bob
> 
> 
> _______________________________________________
> Devl mailing list
> Devl@...
> http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl

--

--