The quantity of movement (m * s) is preserved in the system. "s" stands for the speed *vector*, and "m" for the mass.
Therefore, if you eject something out of the rocket, because the quantity of movement is preserved, you have a "delta s" generated that pushes you in the opposite direction.
Since rockets eject small quantity of material (compared to their mass), they need to eject it at a very high speed so that the rocket gains the opposite quantity of movement.
This is linked with acceleration (which is a variation of speed) but not really as you explained it: What matters is the ejection speed, which creates a delta speed in return.
If we assume the rocket's mass is M and the quantity of particles ejected at instant t is dm, at speed s, and we project the vectors on the propulsion axis, then we have:
0 = dm * s - (M - m) * ds -- Quantity of movement preserved, i.e. = 0
"ds" is the variation in speed of the rocket due to the ejection.
So: ds = (dm * s) / (M - dm)
The fastest "s" is, the higher ds, which is the acceleration gained.
Note that this is true only in space. An airplane ejects matters through its reactors continuously, but we are not in space: there is a reaction force exerced by the air within which the airplane moves. That's why airplanes tend to fly in the higher portions of the atmosphere, were there are less molecules (but still a sufficient supply of O2 molecules, since airplanes are not rockets: they don't embark the oxygen necessary for the combustion).
You have not heard of the Design by Contract paradigm? Because this is what we're talking about here.
In design by contract, the callee makes up the contract (precondition) and the caller promises to never violate the precondition. If you do, it's an error in the caller.
You can choose to enforce the precondition by checking it in the routine. When your software is validated, you can remove this runtime checking. But with design by contract, you never replicate the check of the precondition.
After you have started practicing this paradigm, you will see that your code is clearer, is less cluttered with tests, and more robust than it can be with defensive programming.
You'll see that this can only happen when nItems is 0. This means that if a pre-condition was added to the routine tsort() that the nItems argument MUST be strictly positive, defect #26 vanishes.
If I'd put:
assert(nItems > 0);
at the routine entry, it would prevent the further null-pointer dereference and spot the bug immediately when it occurs. I'm not sure how well a web-server crashing would be perceived, but that would not be worse as a kernel panic'ing, and there is indeed a potential bug there.
My point is that to call #26 a defect (or not), we'd have to check all the callers, and if all the callers were to guarantee that nItems is strictly positive, then there would be no bug at all.
Apart from this remark, I think that kind of work is really great. I'd love to see it applied to my favorite open-source Linux Gnutella client (all Gnutella clients are by definition an HTTP client/server). We'd see how a small open-source project compares to a big one.
There are some countries where publishing some material is illegal, but actually downloading the same material is perfectly legal.
For instance, I believe that in Germany, it is illegal to share MP3 files that are copyrighted, but downloading them is just fine. Please correct me if I'm mistaken, it could be another European country.
Hopefully, in Gnutella at least, one does no longer download files by names but by SHA1. So, yes, I downloaded the file urn:sha1:ABCDEFGHIJKLMNOPQRSTUVWXYZ234567 but I swear I thought it was the latest Linux kernel, and it turned out to be some popular MP3 song.
This is very possible with magnet URIs where you only have the SHA1 URN and possibly a name attached to it, but cannot be sure the two are matching.
Since no download log can tell them what name I thought the file had, it's hard to sue anyone for trying to download in the first place.
No, as long as you are anonymous, you cannot claim your right of reply.
But yes, I think if you say something bad about company XYZ, say, then it is fair that said company be offered the space to react to those accusations.
Note that they already have to right to go to the police and attack you on defamation. In Europe at least, I don't know in the USA.
In Europe, I've seen the "right of reply" used on many occasions in magazines. Most of the time, it was a company reacting to some false statements that had been made by journalists, and they claimed their right to correct that bad impression.
This is so natural a reaction to me that I don't understand all this fuss about that proposal to move that to the Internet publishing space.
Well, call it idiotic if you want, but that's actually a good thing. You should be held liable for your sayings, and if you offend someone, you have at least to give that someone the right to defend himself.
It's only because that someone has that right that *you* have the right to express your opinion. In a reponsible manner. Otherwise, it's the traditional fight where the stronger (the one with access to more media, here) that will always win.
I see that as being really fair. If you don't see it that way, then I'll call you @#$%!@ and you will have ability to defend against that blatent accusation.:-)
I don't see why the Internet could not be viewed as a communication media where the people communicating need to be responsible. Freedom of speach is not incompatible with that!
I have a friend of mine who, way back in 1991, had dissecated his HP calculator (HP-48S). He had found a way (by chance) to read memory through one of the HP-48S functions, and, knowing the chip used, was able to disassemble the ROM of the calculator.
This allowed him to create new functions like ".." to move up the directory hierarchy of the calcultor, or even setup a password-protected login. Cool nerd things.
Anyway, he published his book in France. A few weeks later, he was contacted by HP. They wanted to know how he got those information. He told them and was no further bothered.
Now imagine it would have been in the USA with a DMCA law. This kind of reverse engineering and publishing could have been sanctionned, despite the fact that it did not harm HP a bit, nor did it reveal trade secrets. It merely gave a way for geeks to use the HP-48S in cool new ways.
Back to the topic, I would say that this case shows us how a law can be used against the people that elected their representatives, who in turn voted such a law. Sometehing did not get right here.
The law is the law, it must be applied. At the same time, people must realize that this law is a bad one, that it gives too much power to companies, and that it prevents "fair use".
Selling mod chips is not an activity I would blame. It does not hurt my values, nobody is hurt in the process, and people modify hardware they bought. Yet it is unlawful. If it chokes you as well, it means we both agree the law needs to be changed.
If you don't like that, don't buy this company's hardware. And write to your representative to have the law revisited.
But the DNA is not visible in the pictures of you, is it? However, we're mostly symetrical, which is a form of redundancy visible from the outside.
By the way, the spermatozoids are not issued from a mytosis but from a meyosis, and therefore do not contain the full DNA, but only half of it (half the chromosoms, in fact).
It's good to see that Raphael Hertzog explicitly mentions that Alioth will be reserved to Debian-specific artefacts. At first, I feared that it would be an alternate repository of all the deliverables, including the Debian-packaged distributions. Now that would have been a terrible mistake (duplication, maintenance nightmare, ease of code forking, etc...).
I think it's a good idea to have it separated from Sourceforge. Although it will require dedicated hardware, maintenance, the Sourceforge site is not meant to host distribution-specific bits. At least it's my understanding.
I don't know why most of the comments posted so far are so negative about it. Congratulations to Raphael Hertzog for setting this up. I'm sure it required lots of hours of hard work and discussions.
Instead of blindly punishing (and rather harshly) file traders, I think it would be smarter to consider why people are trading files, and why this activity has blossomed the way it has.
To me, the problem seems to be that music and videos are way too expensive. Consumers are not milk cows and they are ready to pay a fair price. Hence this tremendeous reaction and copyright infringement that occurs today.
View it this way: if it costed you 50 cents to get a song you like in MP3, would you spend time on P2P networks to try to download it "for free"? I don't know how much you evaluate your time and the fun that goes with it, but I would rather pay.
Another aspect is the "sampling" ability. With P2P and file trading, one can listen to music and decide whether it's worth pursuing further with that artist or not.
It is a fact that copyright infringement is not legal. However, is it worth a prison sentence of 3 years? What do we ask from our representatives: that they put up repressive laws to satisfy the lobbies that finance them, or that they serve us and come up with creative way to "fix" our problems.
Today we, as end-users, have a problem with the price of on-line music and videos. We don't need laws to put us in prison.
On my Debian systems, rebooting in single user mode when I have lost my root password would be of no help at all: to enter the single-user shell, I need to type the root password!
If I ever loose my root password, my only way to recover it is to use an emergency boot disk, booting the kernel with a ramdisk whose image is on another disk, with no root password, mount the / on my harddrive to/mnt and edit the/mnt/etc/passwd file to reset (clear) the root password.
That's why I keep boot disks for each of my systems, and update them whenever I change my kernels due to new hardware, or simply because I upgrade to a more recent Linux version.
I could not agree more on whatever you said on Eiffel.
Some will say Java is the Sliver Bullet at OO because it is "better than C++" and "portable". Haha!
Eiffel is truly a unique language. It conveys all the good things I can think of regarding design with OO. And Betrand Meyer's "Object-Oriented Software Construction" is a masterpiece.
I wish more software was written in Eiffel. It's a pity the free Eiffel compilers are not as good as ISE's, and that there is so little Open Source stuff written in Eiffel.
I'd do all my projects in Eiffel if there were.
Re:Variety of standards
on
Gnutella2?
·
· Score: 1
You're seeing only the aspects of connecting to the "network" and be able to search and locate files.
You're not seeing the "sharing" aspects. For instance, Gnutella uses HTTP for file transfers, but adds special headers to help assist in the transfer (alternate locations, SHA1 URNs, etc...).
I don't know what a "plugin" can do in giFT, but it would need to do quite a lot to be able to act as a Gnutella server.
The only value I see in giFT then is the decoupling of the GUI and the network processing node. I know the gtk-gnutella folks have been planning on doing that for more than a year now.
Personally, I'm not interested in using a protocol like openFT, because it is a marginal protocol with few users. It does not have the critical mass Gnutella has today.
[Sorry, I was misconfigured as HTML, but thought it was plain text]
TTH Stands for "Tiger Tree Hash". It's a hash tree, based on the Tiger hash.
You can build a hash tree with any hash really: you could use MD5, or SHA1. Here, Gnutella chose Tiger to build its trees, in case SHA1 gets compromised one day.
The tree is build thusly: say you want to hash a 16 KB file. You will split it into 1KB blocks, and hash them with tiger. You'll get 16 hashes. Then you group those hashes by 2, and compute the Tiger of their concatenation: this yields 8 hashes. You do the same on those 8, which will yield 4, etc... Until you reach one final hash, which will stand as the root hash. This root hash is then a unique identifier for the file, and is called TTH.
What is interesting with tree hashes is not so much the final root hash, but the whole tree (or say, the topmost 10 levels). Knowing the intermediate hashes lets you verify that some piece of a file indeed belongs to the file for which you have the tree.
In our 16KB file example, if I give you the tree and then hand you out a 1KB piece, saying it's the 4th block, you just have to hash it to know whether it is correct. If the file was 1 MB large, you would need log2(1024) levels, i.e. 10, to be able to verify any 1KB block (aligned on its natural boundaries). For larger files, you would need more levels, but then the tree becomes quite large. Gnutella has chosen to keep around 10 levels of the tree for verification purposes, and is using THEX, (Tree Hash EXchange format, which is a serialization format of the tree) to communicate the tree among peers.
When this is widespread, you will be able to quickly verify that a piece you're getting from a servent is indeed the right one, and not a fake. You will also be able to identify the bad parts of a file once it is complete and its TTH does not match the expected one. Instead of re-downloading everything, you will be able to focus on the bad parts only.
The open question then is: why did Gnutella standardize SHA1 first, and not TTH as the standard way to identify files? The partial answer is: it's easier to implement SHA1, and it augments the security, as we will have two independent hashes to tag a file. The concatenation of the SHA1 and the TTH will be known as a "bitprint", as introduced by www.bitzi.com.
I think this simple explaination will do for now. If you want more details, please consult the litterature.
TTH Stands for "Tiger Tree Hash". It's a hash tree, based on the Tiger hash.
You can build a hash tree with any hash really: you could use MD5, or SHA1. Here, Gnutella chose Tiger to build its trees, in case SHA1 gets compromised one day.
The tree is build thusly: say you want to hash a 16 KB file. You will split it into 1KB blocks, and hash them with tiger. You'll get 16 hashes. Then you group those hashes by 2, and compute the Tiger of their concatenation: this yields 8 hashes. You do the same on those 8, which will yield 4, etc... Until you reach one final hash, which will stand as the root hash.
This root hash is then a unique identifier for the file, and is called TTH.
What is interesting with tree hashes is not so much the final root hash, but the whole tree (or say, the topmost 10 levels). Knowing the intermediate hashes lets you verify that some piece of a file indeed belongs to the file for which you have the tree.
In our 16KB file example, if I give you the tree and then hand you out a 1KB piece, saying it's the 4th block, you just have to hash it to know whether it is correct.
If the file was 1 MB large, you would need log2(1024) levels, i.e. 10, to be able to verify any 1KB block (aligned on its natural boundaries). For larger files, you would need more levels, but then the tree becomes quite large.
Gnutella has chosen to keep around 10 levels of the tree for verification purposes, and is using THEX,
(Tree Hash EXchange format, which is a serialization format of the tree) to communicate the tree among peers.
When this is widespread, you will be able to quickly verify that a piece you're getting from a servent is indeed the right one, and not a fake. You will also be able to identify the bad parts of a file once it is complete and its TTH does not match the expected one. Instead of re-downloading everything, you will be able to focus on the bad parts only.
The open question then is: why did Gnutella standardize SHA1 first, and not TTH as the standard way to identify files? The partial answer is: it's easier to implement SHA1, and it augments the security, as we will have two independent hashes to tag a file.
The concatenation of the SHA1 and the TTH will be known as a "bitprint", as introduced by www.bitzi.com.
I think this simple explaination will do for now. If you want more details, please consult the litterature.
Helping!
-- Peer
Re:Gnutella2 - The real story!
on
Gnutella2?
·
· Score: 1
It uses less bandwidth because it implements the Gnutella traffic compression that Raphael Manfredi (of gtk-gnutella) designed and pioneered in a first implementation.
Note that contrary to Shareaza, Raphael did publish the specifications for negotiating traffic compression among peers.
Slashdot Mirror
The quantity of movement (m * s) is preserved in the system. "s" stands for the speed *vector*, and "m" for the mass.
Therefore, if you eject something out of the rocket, because the quantity of movement is preserved, you have a "delta s" generated that pushes you in the opposite direction.
Since rockets eject small quantity of material (compared to their mass), they need to eject it at a very high speed so that the rocket gains the opposite quantity of movement.
This is linked with acceleration (which is a variation of speed) but not really as you explained it: What matters is the ejection speed, which creates a delta speed in return.
If we assume the rocket's mass is M and the quantity of particles ejected at instant t is dm, at speed s, and we project the vectors on the propulsion axis, then we have:
0 = dm * s - (M - m) * ds -- Quantity of movement preserved, i.e. = 0
"ds" is the variation in speed of the rocket due to the ejection.
So: ds = (dm * s) / (M - dm)
The fastest "s" is, the higher ds, which is the acceleration gained.
Note that this is true only in space. An airplane ejects matters through its reactors continuously, but we are not in space: there is a reaction force exerced by the air within which the airplane moves. That's why airplanes tend to fly in the higher portions of the atmosphere, were there are less molecules (but still a sufficient supply of O2 molecules, since airplanes are not rockets: they don't embark the oxygen necessary for the combustion).
You have not heard of the Design by Contract paradigm? Because this is what we're talking about here.
In design by contract, the callee makes up the contract (precondition) and the caller promises to never violate the precondition. If you do, it's an error in the caller.
You can choose to enforce the precondition by checking it in the routine. When your software is validated, you can remove this runtime checking. But with design by contract, you never replicate the check of the precondition.
After you have started practicing this paradigm, you will see that your code is clearer, is less cluttered with tests, and more robust than it can be with defensive programming.
Look at defect ID #26 in the report.
You'll see that this can only happen when nItems is 0. This means that if a pre-condition was added to the routine tsort() that the nItems argument MUST be strictly positive, defect #26 vanishes.
If I'd put:
assert(nItems > 0);
at the routine entry, it would prevent the further null-pointer dereference and spot the bug immediately when it occurs. I'm not sure how well a web-server crashing would be perceived, but that would not be worse as a kernel panic'ing, and there is indeed a potential bug there.
My point is that to call #26 a defect (or not), we'd have to check all the callers, and if all the callers were to guarantee that nItems is strictly positive, then there would be no bug at all.
Apart from this remark, I think that kind of work is really great. I'd love to see it applied to my favorite open-source Linux Gnutella client (all Gnutella clients are by definition an HTTP client/server). We'd see how a small open-source project compares to a big one.
There are some countries where publishing some material is illegal, but actually downloading the same material is perfectly legal.
For instance, I believe that in Germany, it is illegal to share MP3 files that are copyrighted, but downloading them is just fine. Please correct me if I'm mistaken, it could be another European country.
Hopefully, in Gnutella at least, one does no longer download files by names but by SHA1. So, yes, I downloaded the file urn:sha1:ABCDEFGHIJKLMNOPQRSTUVWXYZ234567 but I swear I thought it was the latest Linux kernel, and it turned out to be some popular MP3 song.
This is very possible with magnet URIs where you only have the SHA1 URN and possibly a name attached to it, but cannot be sure the two are matching.
Since no download log can tell them what name I thought the file had, it's hard to sue anyone for trying to download in the first place.
No, as long as you are anonymous, you cannot claim your right of reply.
But yes, I think if you say something bad about company XYZ, say, then it is fair that said company be offered the space to react to those accusations.
Note that they already have to right to go to the police and attack you on defamation. In Europe at least, I don't know in the USA.
In Europe, I've seen the "right of reply" used on many occasions in magazines. Most of the time, it was a company reacting to some false statements that had been made by journalists, and they claimed their right to correct that bad impression.
This is so natural a reaction to me that I don't understand all this fuss about that proposal to move that to the Internet publishing space.
> Is this a requirement for newspapers in Europe?
Yes, it is.
That's the whole point: give Internet communication the same status as printed communication.
I think your conception of free speach needs revisiting.
Your freedom to say anything you want stops as soon as it refrains the ability of someone else to defend himself.
Don't confuse the right of free speach with the right of defamation!
Well, call it idiotic if you want, but that's actually a good thing. You should be held liable for your sayings, and if you offend someone, you have at least to give that someone the right to defend himself.
:-)
It's only because that someone has that right that *you* have the right to express your opinion. In a reponsible manner. Otherwise, it's the traditional fight where the stronger (the one with access to more media, here) that will always win.
I see that as being really fair. If you don't see it that way, then I'll call you @#$%!@ and you will have ability to defend against that blatent accusation.
This is a very good piece of news.
Actually, they are trying to mirror what exists today in the regular printed media. In French, that is called "droit de réponse", and it basically gives the right to anyone offended by the media to have a justice ruling forcing the response to be printed in that same media (if no gentleman agreement is possible).
I don't see why the Internet could not be viewed as a communication media where the people communicating need to be responsible. Freedom of speach is not incompatible with that!
This is sad.
I have a friend of mine who, way back in 1991, had dissecated his HP calculator (HP-48S). He had found a way (by chance) to read memory through one of the HP-48S functions, and, knowing the chip used, was able to disassemble the ROM of the calculator.
This allowed him to create new functions like ".." to move up the directory hierarchy of the calcultor, or even setup a password-protected login. Cool nerd things.
Anyway, he published his book in France. A few weeks later, he was contacted by HP. They wanted to know how he got those information. He told them and was no further bothered.
Now imagine it would have been in the USA with a DMCA law. This kind of reverse engineering and publishing could have been sanctionned, despite the fact that it did not harm HP a bit, nor did it reveal trade secrets. It merely gave a way for geeks to use the HP-48S in cool new ways.
Back to the topic, I would say that this case shows us how a law can be used against the people that elected their representatives, who in turn voted such a law. Sometehing did not get right here.
The law is the law, it must be applied. At the same time, people must realize that this law is a bad one, that it gives too much power to companies, and that it prevents "fair use".
Selling mod chips is not an activity I would blame. It does not hurt my values, nobody is hurt in the process, and people modify hardware they bought. Yet it is unlawful. If it chokes you as well, it means we both agree the law needs to be changed.
If you don't like that, don't buy this company's hardware. And write to your representative to have the law revisited.
But the DNA is not visible in the pictures of you, is it? However, we're mostly symetrical, which is a form of redundancy visible from the outside.
By the way, the spermatozoids are not issued from a mytosis but from a meyosis, and therefore do not contain the full DNA, but only half of it (half the chromosoms, in fact).
It's good to see that Raphael Hertzog explicitly mentions that Alioth will be reserved to Debian-specific artefacts. At first, I feared that it would be an alternate repository of all the deliverables, including the Debian-packaged distributions. Now that would have been a terrible mistake (duplication, maintenance nightmare, ease of code forking, etc...).
I think it's a good idea to have it separated from Sourceforge. Although it will require dedicated hardware, maintenance, the Sourceforge site is not meant to host distribution-specific bits. At least it's my understanding.
I don't know why most of the comments posted so far are so negative about it. Congratulations to Raphael Hertzog for setting this up. I'm sure it required lots of hours of hard work and discussions.
Instead of blindly punishing (and rather harshly) file traders, I think it would be smarter to consider why people are trading files, and why this activity has blossomed the way it has.
To me, the problem seems to be that music and videos are way too expensive. Consumers are not milk cows and they are ready to pay a fair price. Hence this tremendeous reaction and copyright infringement that occurs today.
View it this way: if it costed you 50 cents to get a song you like in MP3, would you spend time on P2P networks to try to download it "for free"? I don't know how much you evaluate your time and the fun that goes with it, but I would rather pay.
Another aspect is the "sampling" ability. With P2P and file trading, one can listen to music and decide whether it's worth pursuing further with that artist or not.
It is a fact that copyright infringement is not legal. However, is it worth a prison sentence of 3 years? What do we ask from our representatives: that they put up repressive laws to satisfy the lobbies that finance them, or that they serve us and come up with creative way to "fix" our problems.
Today we, as end-users, have a problem with the price of on-line music and videos. We don't need laws to put us in prison.
On my Debian systems, rebooting in single user mode when I have lost my root password would be of no help at all: to enter the single-user shell, I need to type the root password!
/mnt and edit the /mnt/etc/passwd file to reset (clear) the root password.
If I ever loose my root password, my only way to recover it is to use an emergency boot disk, booting the kernel with a ramdisk whose image is on another disk, with no root password, mount the / on my harddrive to
That's why I keep boot disks for each of my systems, and update them whenever I change my kernels due to new hardware, or simply because I upgrade to a more recent Linux version.
I could not agree more on whatever you said on Eiffel.
Some will say Java is the Sliver Bullet at OO because it is "better than C++" and "portable". Haha!
Eiffel is truly a unique language. It conveys all the good things I can think of regarding design with OO. And Betrand Meyer's "Object-Oriented Software Construction" is a masterpiece.
I wish more software was written in Eiffel. It's a pity the free Eiffel compilers are not as good as ISE's, and that there is so little Open Source stuff written in Eiffel.
I'd do all my projects in Eiffel if there were.
You're seeing only the aspects of connecting to the "network" and be able to search and locate files.
You're not seeing the "sharing" aspects. For instance, Gnutella uses HTTP for file transfers, but adds special headers to help assist in the transfer (alternate locations, SHA1 URNs, etc...).
I don't know what a "plugin" can do in giFT, but it would need to do quite a lot to be able to act as a Gnutella server.
The only value I see in giFT then is the decoupling of the GUI and the network processing node. I know the gtk-gnutella folks have been planning on doing
that for more than a year now.
Personally, I'm not interested in using a protocol like openFT, because it is a marginal protocol with few users. It does not have the critical mass Gnutella has today.
Thinking!
-- Peer
[Sorry, I was misconfigured as HTML, but thought it was plain text]
TTH Stands for "Tiger Tree Hash". It's a hash tree, based on the Tiger hash.
You can build a hash tree with any hash really: you could use MD5, or SHA1. Here, Gnutella chose Tiger to build its trees, in case SHA1 gets compromised one day.
The tree is build thusly: say you want to hash a 16 KB file. You will split it into 1KB blocks, and hash them with tiger. You'll get 16 hashes. Then you group those hashes by 2, and compute the Tiger of their concatenation: this yields 8 hashes. You do the same on those 8, which will yield 4, etc... Until you reach one final hash, which will stand as the root hash. This root hash is then a unique identifier for the file, and is called TTH.
What is interesting with tree hashes is not so much the final root hash, but the whole tree (or say, the topmost 10 levels). Knowing the intermediate hashes lets you verify that some piece of a file indeed belongs to the file for which you have the tree.
In our 16KB file example, if I give you the tree and then hand you out a 1KB piece, saying it's the 4th block, you just have to hash it to know whether it is correct. If the file was 1 MB large, you would need log2(1024) levels, i.e. 10, to be able to verify any 1KB block (aligned on its natural boundaries). For larger files, you would need more levels, but then the tree becomes quite large. Gnutella has chosen to keep around 10 levels of the tree for verification purposes, and is using THEX, (Tree Hash EXchange format, which is a serialization format of the tree) to communicate the tree among peers.
When this is widespread, you will be able to quickly verify that a piece you're getting from a servent is indeed the right one, and not a fake. You will also be able to identify the bad parts of a file once it is complete and its TTH does not match the expected one. Instead of re-downloading everything, you will be able to focus on the bad parts only.
The open question then is: why did Gnutella standardize SHA1 first, and not TTH as the standard way to identify files? The partial answer is: it's easier to implement SHA1, and it augments the security, as we will have two independent hashes to tag a file. The concatenation of the SHA1 and the TTH will be known as a "bitprint", as introduced by www.bitzi.com.
I think this simple explaination will do for now. If you want more details, please consult the litterature.
Helping!
-- Peer
TTH Stands for "Tiger Tree Hash". It's a hash tree, based on the Tiger hash. You can build a hash tree with any hash really: you could use MD5, or SHA1. Here, Gnutella chose Tiger to build its trees, in case SHA1 gets compromised one day. The tree is build thusly: say you want to hash a 16 KB file. You will split it into 1KB blocks, and hash them with tiger. You'll get 16 hashes. Then you group those hashes by 2, and compute the Tiger of their concatenation: this yields 8 hashes. You do the same on those 8, which will yield 4, etc... Until you reach one final hash, which will stand as the root hash. This root hash is then a unique identifier for the file, and is called TTH. What is interesting with tree hashes is not so much the final root hash, but the whole tree (or say, the topmost 10 levels). Knowing the intermediate hashes lets you verify that some piece of a file indeed belongs to the file for which you have the tree. In our 16KB file example, if I give you the tree and then hand you out a 1KB piece, saying it's the 4th block, you just have to hash it to know whether it is correct. If the file was 1 MB large, you would need log2(1024) levels, i.e. 10, to be able to verify any 1KB block (aligned on its natural boundaries). For larger files, you would need more levels, but then the tree becomes quite large. Gnutella has chosen to keep around 10 levels of the tree for verification purposes, and is using THEX, (Tree Hash EXchange format, which is a serialization format of the tree) to communicate the tree among peers. When this is widespread, you will be able to quickly verify that a piece you're getting from a servent is indeed the right one, and not a fake. You will also be able to identify the bad parts of a file once it is complete and its TTH does not match the expected one. Instead of re-downloading everything, you will be able to focus on the bad parts only. The open question then is: why did Gnutella standardize SHA1 first, and not TTH as the standard way to identify files? The partial answer is: it's easier to implement SHA1, and it augments the security, as we will have two independent hashes to tag a file. The concatenation of the SHA1 and the TTH will be known as a "bitprint", as introduced by www.bitzi.com. I think this simple explaination will do for now. If you want more details, please consult the litterature. Helping! -- Peer
It uses less bandwidth because it implements the Gnutella traffic compression that Raphael Manfredi (of gtk-gnutella) designed and pioneered in a first implementation.
Note that contrary to Shareaza, Raphael did publish the specifications for negotiating traffic compression among peers.
Commenting!
-- Peer