Re: [freenet-support] voip support

2005-07-18 Thread Jens Skripczynski
Diaa Elsayed:
> Greetings,
> 
> Does freenet support voip, like skype?
Well it does not support streaming, so VoIP would be very hard to implement.
Especially you could trace ppl since there a data flow between a <-> b.

   I belief this is a thing freenet wants to avoid
Ciao

Jens Skripczynski
-- 
E-Mail: skripczynski(at)mail2003(dot)skripczynski(dot)de

Life is like a dogsled team; if you ain't the lead dog, the scenery never 
changes.
   -- Lewis Grizzard

___
Support mailing list
Support@freenetproject.org
http://news.gmane.org/gmane.network.freenet.support
Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:[EMAIL PROTECTED]


Re: [freenet-support] network speed

2003-12-20 Thread Jens Skripczynski
Niklas Bergh:
> > -Original Message-
> > From: [EMAIL PROTECTED] 
> > [mailto:[EMAIL PROTECTED] On Behalf Of Jens 
> > Skripczynski
> > Sent: den 17 december 2003 13:35
> > To: [EMAIL PROTECTED]
> > Subject: [freenet-support] network speed
> > 
> > 
> > Hi,
> > 
> > I wanted to as a question about network speed in general.
> > 
> > How effektive does freenet use the total bandwidth assigned 
> > to it ? (e.g. compared to http over TCP/IP). TCP/IP has an 
> > overhead of about 10% and give http another 10%, leaving a 
> > total bandwidth of approx. 80% for Data connections ([1]).
> 
> Freenet doesn't use HTTP between nodes.
Yeah, I know. I wanted to compare  a 'normal' TCP/IP connection
with a 'normal' Protocoll ('http' - could have been FTP, edonk...)
with the freenet protocoll.

With my assumptions I have calculated a percentage, that is lost
by using http over tcp/ip compared to the total bandwidth.
And got that I can use 80%, thus loose 20% to routing, commands
-- overhead.

Next I tried to do the same with freenet, with the knowledge I have
about it.
 
Since I (and the others) do not have a direct connection to the host,
they must use the bandwidth of the other freenet users. Thus the ratio
compared to the http over tcp/ip must be much less. Because if I use 
bandwidth from others, they will use mine, too - And most of the time
at the same ratio.

So now I tried to figure out, how much band-width is lost and got with my
assumptions something around 20% - where you say I'm wrong.
Has somebody done a calculation - experiment figuring out, how good the
actual routing is (like take a netto traffic of  5 MB data and calculate the
brutto amount of data for routing) - next calculate how much bandwidth it
consumes for each node, the calculate the percentage between the total
bandwidth and the netto Bandwidth for data.

Have you a better assumption for freenet ? It is very hard to make an
assumtion from 'varies very much'. Varies very much with an average of 7 hops
is more helpfull...

Ciao

Jens Skripczynski
-- 
E-Mail: skripczynski(at)mail2003(dot)skripczynski(dot)de

Computers are like airconditioners: They stop working 
properly if you open windows.

___
Support mailing list
[EMAIL PROTECTED]
http://news.gmane.org/gmane.network.freenet.support


[freenet-support] network speed

2003-12-17 Thread Jens Skripczynski
Hi,

I wanted to as a question about network speed in general.

How effektive does freenet use the total bandwidth assigned to it ?
(e.g. compared to http over TCP/IP).
TCP/IP has an overhead of about 10% and give http another 10%, leaving
a total bandwidth of approx. 80% for Data connections ([1]).

Next freenet. AFAIK all packets my freenet server sends have to pass a fixed
number of other nodes (chosen random), before reaching their destiny.
AFAIK n is 5 by now. Also freenet has its own overhead, with routing, 
searching,... say 20%.

So lets say I have a total bandwidth of 120kB (6 is a divisor) then I have my
bandwith and the bandwidth of 5 other computers I have to route, thus
having a new bandwidth of 20kB that I can assume to be my own. -20% leaves me
about 16kB. 16/120 = 13 1/3 %.

Could somebody please verify my calculation / assumption ?

Is it really that I have to sacrifice more than 85% of my band-width for 
being somewhat in a state of privacy ?


[1] This is some assumption. It neglects compression in the http protocoll
and others.

Ciao

Jens Skripczynski
-- 
E-Mail: skripczynski(at)mail2003(dot)skripczynski(dot)de

Computers are like airconditioners: They stop working 
properly if you open windows.

___
Support mailing list
[EMAIL PROTECTED]
http://news.gmane.org/gmane.network.freenet.support


Re: [freenet-support] Freenet Stable Build 5036

2003-11-16 Thread Jens Skripczynski
Toad:
> Freenet stable build 5036 is now available. If you are running the
> stable branch (i.e. unless you know what you are doing), please upgrade.
> You can use the update.sh script on *nix, or the freenet-webinstall.exe
> on Windows, to upgrade. Or you can fetch the jar from
> http://freenetproject.org/snapshots/freenet-latest.jar .
> 
> Major changes (since 5034):
> * Fix a major bug in 5034: we weren't taking into account the
> probability of the transfer failing, it was accidentally deleted.
> * Reinstate bandwidth usage based query rejection. This should increase
> transfer rates, reduce the number of connections transferring at once,
> and reduce transfer failure rates.
The last update was a bit too fast, i think.
The built numbers do not seem to me too usefull.
How about releasing things with some freenet-version--pre(1-5) and
freenet-version ?

Where can I get older builds ? I'm able to locate unstable-date
(where i think unstable-builtnumber) is more usefull, since the
Date associated with the jar file tells about the release day


# addign further description to fproxy peer servlet
-
For me (and I think for others) it might be usefull to see which numbers are
good, or bad. e.g. for time i belief smaller is bettern, so it would be great
if somthing like a arrow would point to the better performance.
  | lookup time  0 10  << better
--
host1 |   
host2 |   ###
host3 |   

Thus host 2 does perform well.


# adding general information to fproxy servlet
-

Like:
versionnumber, amount and perentage of the connected hosts
version | # host | %
5029| 10 | 50
5036|  5 | 25
6031|  3 | 15
6033|  2 | 10

Packet input/output, Waiting input output, total load over time statistic (a
nice picture :)

So one can see, if one's node stays on overload over time (90-100% load). 
If routing improves (packet output,...).


Ciao

Jens Skripczynski
-- 
E-Mail: skripczynski(at)mail2003(dot)skripczynski(dot)de

The Golden Rule of Arts and Sciences:
He who has the gold makes the rules.

___
Support mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support


Re: [freenet-support] Freenet Stable Build 5032

2003-11-11 Thread Jens Skripczynski
Hi,

good job !

These releases give me a feeling something is working and it is communicated
to the community interested in the information.

Toad:
> Freenet stable build 5032 is now available. Use your update utility to
> upgrade (freenet-webinstall.exe or update.sh depending on platform). It
> is also available from
> http://freenetproject.org/snapshots/freenet-latest.jar (stop your node, 
> install this over your current freenet.jar, start your node).
> Changes:
> * LOTS OF BUG FIXES, in fairly important areas. Examples:
> - Estimates of transfer rates could be ludicrously high.
> - The global success time estimator wasn't (wasn't always?) written out
>   on Windows, leading to bad routing on startup.
> - Don't drop our best nodes while restarting because they aren't
>   connected yet, if they have recent successes.
> - Fix announcements to nodes not in the routing table or otherwise
>   connected.
> - Fix bug in padding a trailer out when we abort it, may have caused
>   connections to be closed for no good reason.
> - Some NullPointerExceptions.
> * Major changes to the failure table (system that tries to reduce load
>   from retries of recently failed keys)
> - Fixed architectural bugs, should increase effectiveness.
> - Implement "secondary failure table", which has been described
>   recently, to improve accuracy of estimators and statistics using an
>   extension to the failure table.
> * Various new diagnostic variables: outputBytesTrailingAttempted,
>   searchFailedCount, diffSuccessSearchTime, absDiffSuccessSearchTime,
>   diffTransferRate, absDiffTransferRate, routingSuccessRatioCHK. All are
>   documented on the Diagnostics page in the node status servlet.
> * Major changes to the Open Connections page, Peers mode is now default,
>   and is extremely verbose.
> * Show an estimate of nodes' max and min estimated transfer rates on the
>   routing table summary page.
> * Internal code improvements, improved logging etc.
> -- 
> Matthew J Toseland - [EMAIL PROTECTED]
> Freenet Project Official Codemonkey - http://freenetproject.org/
> ICTHUS - Nothing is impossible. Our Boss says so.



> ___
> Support mailing list
> [EMAIL PROTECTED]
> http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support

Ciao

Jens Skripczynski
-- 
E-Mail: skripczynski(at)mail2003(dot)skripczynski(dot)de

Today is yesterday's pupil.
   -- Thomas Fuller

___
Support mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support