iptables -A OUTPUT -p TCP -d 64.28.67.114 --dport 80 -j DROP iptables -A OUTPUT -p TCP -d 199.95.206.210 --dport 80 -j DROP
64.28.67.114 is images2.slashdot.org, where the banner ads come from. The other IP is from doubleclick.net, which gets rid of the more annoying huge ads.
Try it, it works. And I can leave JavaScript turned off...
But I am not content with possibilities and maybes. He has shown an effective way to greatly increase the capability of simple hardware to attack large integer factorization. This alone is enough to make me nervous. Do you really want to bet your security on possibilities?
I already use a 4096bit ElGamal key. I would suggest others do the same.
And regarding the rather tame developments in the crypto field (this is becoming old, well explored territory, not much new happens these days) I still think this is signifigant.
HTTP works great for a large number of purposes. It will continue to work great for a large number of purposes. However, it is not so great when you are trying to build powerful RPC mechanisms like SOAP on top of it. It's the latter where HTTP will slowly loose favor.
Your web browser will still be making HTTP requests for HTML documents many years into the future...
"Holy shit. The math works. Bernstein has found ways using additional hardware to eliminate redundancies and inefficiencies which appear in any linear implementation of the Number Field Sieve. We just never noticed that they were inefficiencies an redundancies because we kept thinking in terms of linear implementations. This is probably the bigest news in crypto in the last decade."
Yeah, this is big news. It also sheds new light on the relaxation of the export constraints. The NSA has dedicated hardware performing this same procesing, and probably for the last 5-10 years...
"Note that there have been rumors of an RSA cracker built by a three-letter agency in custom silicon before this, but until analyzing Bernstein's paper I had always dismissed as ridiculous paranoid fantasies. Now it looks like such a device is entirely feasible and, in fa ct very likely."
I know:-) I wish we had true multicast. When that day comes, alpine will no longer be needed, and all these other cool projects that are confined to the realm of educational networks (where multicast is supported) can be brought out into the open.
IPv6 might be the answer. Although perhaps ISP's will cut multicast out of v6 as well.
*sigh*
At any rate, distributed multicast is unappealing to me, if only for the reason that there is trust implied. How do I know that peer X is really going to forward those packets? If I could answer that question, then I would be much more amenable to it. I am working under the assumption that I can trust no peer, which may be one of those bad design goals where you pay a high price for something that is of little or no value in return (i.e. malicious non forwarding peers will be rare/non existant)
And the amount of code to add distributed multicast support is hurting my head just thinking about it... *grin*
Circle is cool, but it is really a subset of Chord, with searching kind of hacked on top of a hashing index system (i.e. search is implemented by tying keywords to hashes and distributing this hash space.)
This means that high peer churn rates, hot spots in popular keywords, spamming keywords, etc, all make this a rather vulnerable and fragile implementation of searching. It probably is better than gnutella, but that isnt saying much, and it certainly does not mean it is 'infinitely scalable'. The real world is a harsh place...
If you want a scalable, distributed search/discovery mechanism for large peer networks here is your recipe:
1. Build on a base of juicy lightweight UDP messaging. This allows you to send messages directly to peers, circumvent NAT's, and handle many thousands of virtual connections.
2. Sending queries to many thousands of peers is still a large task, even if only small packets are sent directly. Must optimize this.
3. Optimize by using a social discovery mechanism to keep track of which peers are good at answering your queries. Query them first and more often than other peers. Call this peer ranking the 'relative quality' of the peer.
4. Optimize further by halting the query once a sufficient number of matches are found. This way you only need to query a handfull of peers (maybe 10, maybe 200) to complete a query.
5. Finally, perform transitive introduction using the high quality peers in your group. This way you use peers with a high quality to find new peers, and it is highly likely that they will be high quality peers as well.
This is how the ALPINE Network works, and it scales. The number of connections any peer may have is solely up to their discretion, based on bandwidth and memory resources. All communication is direct, and every peer is in direct control over his own resources, which makes for a very robust environment.
There are a number of details, the above simply a 30,000ft description. If you are interested you can read more in the ALPINE Overview and the ALPINE FAQ.
What I find most interesting are the kinds of projects that have sprung up in Gnutella's wake. Many of these started out as attempts to improve Gnutella, and have since moved on (the Gnutella Next Generation working group never really materialized into anything)
We had napster and one extreme, gnutella at the other, and in the middle a re a number of partially centralized systems with super peers like Fast Track, such as:
Open FT JXTA Search GNet NEShare
and many others...
Then there are the alternative projects that use an entirely different mechanism. For example, social discovery as implemented in:
NeuroGrid ALPINE
The coming year(s) will see a lot of maturity in these areas, and searching large peer networks will become ever more efficient over time. Gnutella showed us the possibilities of a fully decentralized model, and refinements of its underlying architecture can produce vastly better solutions.
2002 will be an interesting year for peer networking applications...
If you read the article they mention that any voice and video or other data transfer mechansim integrated into instant messaging *must* support congestion control. Funny they mention that because TCP has congestion control, and works just fine (TCP traffic will not collapse the net)
Later on you read about various existing technologies that use UDP, and this is what the IETF is concerned about. Traditionally voice and real time video require low latency transmission where order and reliability is not as critical as latency. These applications use UDP specifically for this purpose, and this is why the IETF is concerned.
They are deathly afraid that AOL or MSN or some other giant will release a chat client that supports voice or video using a UDP transport, without congestion control, and that all these millions of users spewing UDP packets into the net will cause a congestion meltdown.
The probability of this happening is about zero. Any network programmer worth half a grain of salt would know about the problems inherent in using UDP, and for general MP3 file sharing, etc, they would integrate a TCP based transport (AIMster already does this, as do many others. Think/dcc for IM clients)
So this article is really much ado about nothing. No one is going to use UDP to transfer mp3's, and no one is going to integrate reltime voice/video into an IM application without working out the congestion control details.
I think this is more of a publicity stunt than anything else...
There is another method for ensuring cooperation and fair behavior in peer networks. And it works the same was as the method described.
It is called social discovery, and it works by having each and every peer create a view of the network that suits their interests and needs. In such an environment, the freeloading peers will not be viewed as valuable peers and will be dropped from your peer group(s); no longer used, and no longer using your resources.
On the flip side, there is a strong incentive to become a better, more reliable peer yourself, as the quality of peers you can associate with is directly related to how they perceive *your* quality to them.
If you want to be able to tap better, higher quality peers, then you should keep your node available longer, more often, and also share more resources (whatever they may be).
The project I am working on that implements this social discovery mechanism is called the ALPINE Network and there is also another social discovery based project called NeuroGrid.
I am biased towards this kind of approach, but I think it provides the best long term solution to resource discovery / searching in large peer networks.
You are counting documentation as lines of code. Documentation is not code. While documentations is REQUIRED to write decent code (i.e. decent code requires decent documentation within the code / included with the code), it is not part of the code itself.
If you want to be accurate, you would have had to say that there are 250,000 lines of code, documentation, and whitespace.
I recounted including treecc and pnetlib (both of which are very small in comparison) which includes both the *.tc files, as well as the *.cs files and the updated totals are:
Total Physical Source Lines of Code (SLOC) = 209,300
Development Effort Estimate, Person-Years = 54.68
Schedule Estimate, Years = 2.45
Estimated Average Number of Developers = 22.32
Total Estimated Cost to Develop = $ 7,386,680
And that includes 18,000 lines of code in shell scripts (which I usually dont consider either).
If you wanted a true estimate of all code (excluding shell scripts used in configuration, etc) then you are looking at somewhere around: 191,676 SLOC.
Your confusing the results.
It would take one average developer 38.37 years to write that much code.
OR it would take a group of 17.92 average developers 2.4 years to write that much software.
This is by no means incredible, it makes sense. There is a huge difference in productivity between average programmers and extremely capable programmers. This is a well known phenomenon.
There is also a lot less than 'average' amount of documentation, testing, and design going on in his work, which makes the SLOC count rise as well.
Remember, this is all averages and assumptions. Its not 'the law'.
This tool basically counts phsysical lines of code (non comments or whitespace) and produces cost and schedule estimates on this count using the standard COCOMO model.
Which is still a fuckload of code. I used sloccount, which is not perfect, but is a pretty informative tool none the less.
./sloccount/tmp/pnet/pnet-0.2.6
Totals grouped by language (dominant language first)
ansic: 121564 (81.39%)
sh: 17160 (11.49%)
yacc: 5634 (3.77%)
lex: 2091 (1.40%)
asm: 1937 (1.30%)
cpp: 961 (0.64%)
exp: 20 (0.01%)
Total Physical Source Lines of Code (SLOC) = 149,367
Development Effort Estimate, Person-Years = 38.37
Schedule Estimate, Years = 2.14
Estimated Average Number of Developers = 17.92
Total Estimated Cost to Develop = $ 5,183,332
It appears that the damn lameness filter is preventing me from posting this, so i have trimmed the output a bit.
... but for P2P, TCP/IP is probably the highest-level standard we need.
And in some cases, even TCP is too high level. One of the significant problems with peer networks is handling NAT's and using bandwidth efficiently.
A project I am working on requires a lot of very small messaging data be sent to a lot of peers directly. For this situation, UDP/IP is the best choice.
Not only does this UDP based protocol cross dual NAT chasms that TCP cant touch, but it is also very low overhead for simple messaging in terms of bandwidth and kernel.
But your basic premise still stands. JXTA will probably be usefull for many things, but it no way will it be usefull for _ALL_ things peer oriented. There is just too much diversity in requirements and functionality for JXTA to hope to support.
Well, not Everyone is OR and WA is converted yet, but most are. No one at all is converted outside of OR and WA.
If you have connectivity, you will know it because every site to try to reach will take you to the AT&T network migration page. Then you can use the above to get things working again.
If you are in one of those two states, you will notice that your cable modem is still synch'ed up, and that any site you try and reach will take you to this AT&T page:
1. Fire up a dhcp client. In my case, all I needed to issue was the command:
$ dhcpcd eth1
2. Check your DNS servers (/etc/resolv.conf) and remove any of the old @home servers. The new IPs I got were:
204.127.198.4
63.240.76.4
3. If you have any machines inside a NAT network, you need to update their DNS server lists as well (unless your gateway is set as the DNS)
4. Change your outgoing SMTP server to mail.attbi.com instead of the *.home.com host.
And that should do it! I was actually surprised how easy it was to get back online after they made the changes. I was dreading bringing out the old 56k modem again.
Lets home the remaining states get their access back soon as well...
I have a RIO Volt, and it can play CD-RW's as well.
I would highly reccomend this system. Simply burn firmware upgrades to a CD-RW and the player will upgrade as soon as it sees the file on the CD. Pretty slick.
Audio quality is fine, although I dont thave the Volt-90 or whatever the cheapie model is (perhaps it has the problems)
All in all a great system. You can pack quite a bit of music on a 700M CDR. I will listed for hours, sometimes days on end before it loops back to the beginning.
I have used ACE and TAO (the ACE CORBA ORB) for a number of projects.
It works great and is incredibly portable. My only advice is to be sure to get familiar with the configuration of the entire package, like features and options and components before you settle on a given configuration for use in your project.
ACE+TAO are designed to run on a large number of platforms, and support C++ without exceptions, explicit STL template definition, and a number of other features which are really handy for some environments, but dont serve a default installation well.
Some of these options affect the way your code interacts with the library, and require you to write and/or compile your code accordingly. Obviously you do not want to get half way into a project and realize you need to change some configuration options, and then go back into your code and make the requisite changes to support these modified configurations. (This isnt a big deal, as everything is pretty well encapsulated, but it can cause headaches)
I'll give you a few examples of things that I ran across.
1. CORBA. I had used the TAO orb to compile IDL without native exceptions, producing stubs and skeletons that used a CORBA::Environment arguments in all methods to provide the hooks necessary to handle exceptions without using c++ exceptions. Later I switched to native c++ exceptions, and had to modify the function declarations and definitions to remove this now unnecessary CORBA::Environment argument.
2. I had built ACE with the 'no implicit templates' option, which required that all member templates be explicitly defined in the sources files where they were used for linking correctly. Later I switched to gcc 3.0.2 and started using implicit templates. I had to recompile ACE with this new configuration, and also modify my code to remove all of the explicit template definitions that I had added.
3. I had initially been building ACE + TAO with all components and features enabled. This led to very, very long compile times (I am talking 8+ hours on a dual PIII 550 w/ 512M of RAM!) It turns out a vast majority of the stuff being built I didnt need, like a number of the CoS services, the realtime CORBA stuff, and some of the ATM and other networking features. I was able to tweak a few settings in the configuration / build files and this cut my build times down to about an hour. This is a BIG time saver.
And we need to pay developer's salaries--like mine--to keep driving innovation on the Gnutella network.
Gnutella and peer networks in general are going to continue evolving and innovating regardless of whether you specifically are involved.
If there is one thing I hate about all these projects it is the lame excuses for significant and broad invasions of privacy by people who cannot build a decent business model.
Instead they take a short cut, sell privacy invasion for a quick fix, and say that it is all for the good of the user.
Just because it makes money does not mean spyware is a proper or even tolerable method of funding work on your project or business, regardless of what it is.
Peer networks are about empowering and utilizing individuals communicating at the edge of the network. Invading their privacy like this defeats the purpose and sells everyone short.
The last thing in the world you want to is stick with tech even though you dislike it, or it bores you.
Keeping current on your technology skills requires constant maintenance and efforyt. If you dont have the desire, your skills are going to suffer. It will only get worse with time.
My suggestion would be to experiment and explore other areas of interest that you enjoy.
Tech is used in just about every field of study nowadays, and perhaps applying technology to a different domain, like sociology, archeology, etc, would be a usefull application of your skills, as well as something that you look forward to.
Don't sell yourself short. 'Settling' on a tech career because of the money won't bring any satisfaction, and probably won't bring the money you thought it would either.
A little later we hit the "IPv6 will help" argument, to which I can only say: security. Sure, you get rid of NAT. But at the risk of placing your device in the line of fire.... That means DOS vulnerable, attack vulnerable when a security hole is found, and each and every individual is responsible for their own security.
Glad to know that firewalls dont work unless you have a NAT in there!
Actually, NAT and individual addressing have nothing to do with security. Firewalls can filter subnets just as easily as they can filter a single IP.
Also regarding SOAP and HTTP tunneling, etc, your blowing smoke. If your firewalls allows outgoing TCP connections (like all of them?) then you can tunnel protocols. If someone wants to do it, they can. This is a non issue.
This isn't really a practical attack, at the very best case, you'd need to be able to upload 1/100th of the entire storage space usable by Freenet in a reasonably small amount of time
Wrong. Read the Freenet architecture docs.
No, that's not true. The Freenet 0.3 java node can use up to the maximum bytes/files a single directory in the underlying filesystem. The Freenet 0.4 java node can use up to the maximum size of a single file in the underlying file system (or 2^63-1 bytes, whichever is less).
Wrong again. Due to implementation limits you can only use a maximum 2G datastore.
Slashdot Mirror
There is a Google Experiment underway to see if search results for Scientology can be reclaimed.
:-)
Only a few thousands links more needed...
Linux users:
iptables -A OUTPUT -p TCP -d 64.28.67.114 --dport 80 -j DROP
iptables -A OUTPUT -p TCP -d 199.95.206.210 --dport 80 -j DROP
64.28.67.114 is images2.slashdot.org, where the banner ads come from. The other IP is from doubleclick.net, which gets rid of the more annoying huge ads.
Try it, it works. And I can leave JavaScript turned off...
True, perhaps I worded my reply too strongly.
But I am not content with possibilities and maybes. He has shown an effective way to greatly increase the capability of simple hardware to attack large integer factorization. This alone is enough to make me nervous. Do you really want to bet your security on possibilities?
I already use a 4096bit ElGamal key. I would suggest others do the same.
And regarding the rather tame developments in the crypto field (this is becoming old, well explored territory, not much new happens these days) I still think this is signifigant.
"HTTP's days as an RPC transport are numbered"
HTTP works great for a large number of purposes. It will continue to work great for a large number of purposes. However, it is not so great when you are trying to build powerful RPC mechanisms like SOAP on top of it. It's the latter where HTTP will slowly loose favor.
Your web browser will still be making HTTP requests for HTML documents many years into the future...
"Holy shit. The math works. Bernstein has found ways using additional hardware to eliminate redundancies and inefficiencies which appear in any linear implementation of the Number Field Sieve. We just never noticed that they were inefficiencies an redundancies because we kept thinking in terms of linear implementations. This is probably the bigest news in crypto in the last decade."
Yeah, this is big news. It also sheds new light on the relaxation of the export constraints. The NSA has dedicated hardware performing this same procesing, and probably for the last 5-10 years...
"Note that there have been rumors of an RSA cracker built by a three-letter agency in custom silicon before this, but until analyzing Bernstein's paper I had always dismissed as ridiculous paranoid fantasies. Now it looks like such a device is entirely feasible and, in fa ct very likely."
Time to make new keys...
I know :-) I wish we had true multicast. When that day comes, alpine will no longer be needed, and all these other cool projects that are confined to the realm of educational networks (where multicast is supported) can be brought out into the open.
IPv6 might be the answer. Although perhaps ISP's will cut multicast out of v6 as well.
*sigh*
At any rate, distributed multicast is unappealing to me, if only for the reason that there is trust implied. How do I know that peer X is really going to forward those packets? If I could answer that question, then I would be much more amenable to it. I am working under the assumption that I can trust no peer, which may be one of those bad design goals where you pay a high price for something that is of little or no value in return (i.e. malicious non forwarding peers will be rare/non existant)
And the amount of code to add distributed multicast support is hurting my head just thinking about it... *grin*
Circle is cool, but it is really a subset of Chord, with searching kind of hacked on top of a hashing index system (i.e. search is implemented by tying keywords to hashes and distributing this hash space.)
.
:-)
This means that high peer churn rates, hot spots in popular keywords, spamming keywords, etc, all make this a rather vulnerable and fragile implementation of searching. It probably is better than gnutella, but that isnt saying much, and it certainly does not mean it is 'infinitely scalable'. The real world is a harsh place...
If you want a scalable, distributed search/discovery mechanism for large peer networks here is your recipe:
1. Build on a base of juicy lightweight UDP messaging. This allows you to send messages directly to peers, circumvent NAT's, and handle many thousands of virtual connections.
2. Sending queries to many thousands of peers is still a large task, even if only small packets are sent directly. Must optimize this.
3. Optimize by using a social discovery mechanism to keep track of which peers are good at answering your queries. Query them first and more often than other peers. Call this peer ranking the 'relative quality' of the peer.
4. Optimize further by halting the query once a sufficient number of matches are found. This way you only need to query a handfull of peers (maybe 10, maybe 200) to complete a query.
5. Finally, perform transitive introduction using the high quality peers in your group. This way you use peers with a high quality to find new peers, and it is highly likely that they will be high quality peers as well.
This is how the ALPINE Network works, and it scales. The number of connections any peer may have is solely up to their discretion, based on bandwidth and memory resources. All communication is direct, and every peer is in direct control over his own resources, which makes for a very robust environment.
There are a number of details, the above simply a 30,000ft description. If you are interested you can read more in the ALPINE Overview and the ALPINE FAQ
One last comment, this stuff is no longer vaporware
What I find most interesting are the kinds of projects that have sprung up in Gnutella's wake. Many of these started out as attempts to improve Gnutella, and have since moved on (the Gnutella Next Generation working group never really materialized into anything)
We had napster and one extreme, gnutella at the other, and in the middle a re a number of partially centralized systems with super peers like Fast Track, such as:
Open FT
JXTA Search
GNet
NEShare
and many others...
Then there are the alternative projects that use an entirely different mechanism. For example, social discovery as implemented in:
NeuroGrid
ALPINE
Or distributed keyword hash indexes like:
Chord
Circle
GISP
JXTA Distributed Indexing
And many others as well.
The coming year(s) will see a lot of maturity in these areas, and searching large peer networks will become ever more efficient over time. Gnutella showed us the possibilities of a fully decentralized model, and refinements of its underlying architecture can produce vastly better solutions.
2002 will be an interesting year for peer networking applications...
If you read the article they mention that any voice and video or other data transfer mechansim integrated into instant messaging *must* support congestion control. Funny they mention that because TCP has congestion control, and works just fine (TCP traffic will not collapse the net)
/dcc for IM clients)
Later on you read about various existing technologies that use UDP, and this is what the IETF is concerned about. Traditionally voice and real time video require low latency transmission where order and reliability is not as critical as latency. These applications use UDP specifically for this purpose, and this is why the IETF is concerned.
They are deathly afraid that AOL or MSN or some other giant will release a chat client that supports voice or video using a UDP transport, without congestion control, and that all these millions of users spewing UDP packets into the net will cause a congestion meltdown.
The probability of this happening is about zero. Any network programmer worth half a grain of salt would know about the problems inherent in using UDP, and for general MP3 file sharing, etc, they would integrate a TCP based transport (AIMster already does this, as do many others. Think
So this article is really much ado about nothing. No one is going to use UDP to transfer mp3's, and no one is going to integrate reltime voice/video into an IM application without working out the congestion control details.
I think this is more of a publicity stunt than anything else...
There is another method for ensuring cooperation and fair behavior in peer networks. And it works the same was as the method described.
It is called social discovery, and it works by having each and every peer create a view of the network that suits their interests and needs. In such an environment, the freeloading peers will not be viewed as valuable peers and will be dropped from your peer group(s); no longer used, and no longer using your resources.
On the flip side, there is a strong incentive to become a better, more reliable peer yourself, as the quality of peers you can associate with is directly related to how they perceive *your* quality to them.
If you want to be able to tap better, higher quality peers, then you should keep your node available longer, more often, and also share more resources (whatever they may be).
The project I am working on that implements this social discovery mechanism is called the ALPINE Network and there is also another social discovery based project called NeuroGrid.
I am biased towards this kind of approach, but I think it provides the best long term solution to resource discovery / searching in large peer networks.
You are counting documentation as lines of code. Documentation is not code. While documentations is REQUIRED to write decent code (i.e. decent code requires decent documentation within the code / included with the code), it is not part of the code itself.
If you want to be accurate, you would have had to say that there are 250,000 lines of code, documentation, and whitespace.
I recounted including treecc and pnetlib (both of which are very small in comparison) which includes both the *.tc files, as well as the *.cs files and the updated totals are:
Total Physical Source Lines of Code (SLOC) = 209,300
Development Effort Estimate, Person-Years = 54.68
Schedule Estimate, Years = 2.45
Estimated Average Number of Developers = 22.32
Total Estimated Cost to Develop = $ 7,386,680
And that includes 18,000 lines of code in shell scripts (which I usually dont consider either).
If you wanted a true estimate of all code (excluding shell scripts used in configuration, etc) then you are looking at somewhere around: 191,676 SLOC.
Anyway, this is all an academic argument.
Your confusing the results.
It would take one average developer 38.37 years to write that much code.
OR it would take a group of 17.92 average developers 2.4 years to write that much software.
This is by no means incredible, it makes sense. There is a huge difference in productivity between average programmers and extremely capable programmers. This is a well known phenomenon.
There is also a lot less than 'average' amount of documentation, testing, and design going on in his work, which makes the SLOC count rise as well.
Remember, this is all averages and assumptions. Its not 'the law'.
I should have posted a link to the tool which can be found at: http://www.dwheeler.com/sloccount/.
This tool basically counts phsysical lines of code (non comments or whitespace) and produces cost and schedule estimates on this count using the standard COCOMO model.
Which is still a fuckload of code. I used sloccount, which is not perfect, but is a pretty informative tool none the less.
/tmp/pnet/pnet-0.2.6
./sloccount
Totals grouped by language (dominant language first)
ansic: 121564 (81.39%)
sh: 17160 (11.49%)
yacc: 5634 (3.77%)
lex: 2091 (1.40%)
asm: 1937 (1.30%)
cpp: 961 (0.64%)
exp: 20 (0.01%)
Total Physical Source Lines of Code (SLOC) = 149,367
Development Effort Estimate, Person-Years = 38.37
Schedule Estimate, Years = 2.14
Estimated Average Number of Developers = 17.92
Total Estimated Cost to Develop = $ 5,183,332
It appears that the damn lameness filter is preventing me from posting this, so i have trimmed the output a bit.
this thing is going to end up in the Smithsonian on display as a proud emblem of the geekiness of the early internet.
:-)
Somehow I find this both amusing and disturbing.
When I saw the first showing there where two guys behind me who kept cracking up whenever Huge spoke.
"ehehehe.. heheh.. it just doesn't work!"
And I have to admit that as hard as I tried, he was still the goddamn agent, mocking Neo with his monotonous speach. Does he do that on purpose?
Hugo's character was the only thing that I found slightly out of place and annoying in the film.
... but for P2P, TCP/IP is probably the highest-level standard we need.
And in some cases, even TCP is too high level. One of the significant problems with peer networks is handling NAT's and using bandwidth efficiently.
A project I am working on requires a lot of very small messaging data be sent to a lot of peers directly. For this situation, UDP/IP is the best choice.
Not only does this UDP based protocol cross dual NAT chasms that TCP cant touch, but it is also very low overhead for simple messaging in terms of bandwidth and kernel.
But your basic premise still stands. JXTA will probably be usefull for many things, but it no way will it be usefull for _ALL_ things peer oriented. There is just too much diversity in requirements and functionality for JXTA to hope to support.
Well, not Everyone is OR and WA is converted yet, but most are. No one at all is converted outside of OR and WA.
If you have connectivity, you will know it because every site to try to reach will take you to the AT&T network migration page. Then you can use the above to get things working again.
If you are in one of those two states, you will notice that your cable modem is still synch'ed up, and that any site you try and reach will take you to this AT&T page:
http://transition-aid.attbi.com/attbi_welcome_pag
This is because you are using the OLD @home nameservers, which AT&T has replaced to resolve ALL DNS lookups to their migration help site.
The fix is as simple as it reads in the Manually Configuring Unsupported Operating Systems page
1. Fire up a dhcp client. In my case, all I needed to issue was the command:
- $ dhcpcd eth1
2. Check your DNS servers (/etc/resolv.conf) and remove any of the old @home servers. The new IPs I got were:-
204.127.198.4
3. If you have any machines inside a NAT network, you need to update their DNS server lists as well (unless your gateway is set as the DNS)63.240.76.4
4. Change your outgoing SMTP server to mail.attbi.com instead of the *.home.com host.
And that should do it! I was actually surprised how easy it was to get back online after they made the changes. I was dreading bringing out the old 56k modem again.
Lets home the remaining states get their access back soon as well...
I have a RIO Volt, and it can play CD-RW's as well.
I would highly reccomend this system. Simply burn firmware upgrades to a CD-RW and the player will upgrade as soon as it sees the file on the CD. Pretty slick.
Audio quality is fine, although I dont thave the Volt-90 or whatever the cheapie model is (perhaps it has the problems)
All in all a great system. You can pack quite a bit of music on a 700M CDR. I will listed for hours, sometimes days on end before it loops back to the beginning.
I have used ACE and TAO (the ACE CORBA ORB) for a number of projects.
It works great and is incredibly portable. My only advice is to be sure to get familiar with the configuration of the entire package, like features and options and components before you settle on a given configuration for use in your project.
ACE+TAO are designed to run on a large number of platforms, and support C++ without exceptions, explicit STL template definition, and a number of other features which are really handy for some environments, but dont serve a default installation well.
Some of these options affect the way your code interacts with the library, and require you to write and/or compile your code accordingly. Obviously you do not want to get half way into a project and realize you need to change some configuration options, and then go back into your code and make the requisite changes to support these modified configurations. (This isnt a big deal, as everything is pretty well encapsulated, but it can cause headaches)
I'll give you a few examples of things that I ran across.
1. CORBA. I had used the TAO orb to compile IDL without native exceptions, producing stubs and skeletons that used a CORBA::Environment arguments in all methods to provide the hooks necessary to handle exceptions without using c++ exceptions. Later I switched to native c++ exceptions, and had to modify the function declarations and definitions to remove this now unnecessary CORBA::Environment argument.
2. I had built ACE with the 'no implicit templates' option, which required that all member templates be explicitly defined in the sources files where they were used for linking correctly. Later I switched to gcc 3.0.2 and started using implicit templates. I had to recompile ACE with this new configuration, and also modify my code to remove all of the explicit template definitions that I had added.
3. I had initially been building ACE + TAO with all components and features enabled. This led to very, very long compile times (I am talking 8+ hours on a dual PIII 550 w/ 512M of RAM!) It turns out a vast majority of the stuff being built I didnt need, like a number of the CoS services, the realtime CORBA stuff, and some of the ATM and other networking features. I was able to tweak a few settings in the configuration / build files and this cut my build times down to about an hour. This is a BIG time saver.
And we need to pay developer's salaries--like mine--to keep driving innovation on the Gnutella network.
Gnutella and peer networks in general are going to continue evolving and innovating regardless of whether you specifically are involved.
If there is one thing I hate about all these projects it is the lame excuses for significant and broad invasions of privacy by people who cannot build a decent business model.
Instead they take a short cut, sell privacy invasion for a quick fix, and say that it is all for the good of the user.
Just because it makes money does not mean spyware is a proper or even tolerable method of funding work on your project or business, regardless of what it is.
Peer networks are about empowering and utilizing individuals communicating at the edge of the network. Invading their privacy like this defeats the purpose and sells everyone short.
The last thing in the world you want to is stick with tech even though you dislike it, or it bores you.
Keeping current on your technology skills requires constant maintenance and efforyt. If you dont have the desire, your skills are going to suffer. It will only get worse with time.
My suggestion would be to experiment and explore other areas of interest that you enjoy.
Tech is used in just about every field of study nowadays, and perhaps applying technology to a different domain, like sociology, archeology, etc, would be a usefull application of your skills, as well as something that you look forward to.
Don't sell yourself short. 'Settling' on a tech career because of the money won't bring any satisfaction, and probably won't bring the money you thought it would either.
A little later we hit the "IPv6 will help" argument, to which I can only say: security. Sure, you get rid of NAT. But at the risk of placing your device in the line of fire. ... That means DOS vulnerable, attack vulnerable when a security hole is found, and each and every individual is responsible for their own security.
Glad to know that firewalls dont work unless you have a NAT in there!
Actually, NAT and individual addressing have nothing to do with security. Firewalls can filter subnets just as easily as they can filter a single IP.
Also regarding SOAP and HTTP tunneling, etc, your blowing smoke. If your firewalls allows outgoing TCP connections (like all of them?) then you can tunnel protocols. If someone wants to do it, they can. This is a non issue.
This isn't really a practical attack, at the very best case, you'd need to be able to upload 1/100th of the entire storage space usable by Freenet in a reasonably small amount of time
Wrong. Read the Freenet architecture docs.
No, that's not true. The Freenet 0.3 java node can use up to the maximum bytes/files a single directory in the underlying filesystem. The Freenet 0.4 java node can use up to the maximum size of a single file in the underlying file system (or 2^63-1 bytes, whichever is less).
Wrong again. Due to implementation limits you can only use a maximum 2G datastore.