i did not moderate your post - i never do this. actually i have no idea how to do this.
regarding research - i can very well and proffessionaly advise investors
anyway nothing bad happened, this is just a post, one among many
have a nice day
you can find interesting one idea from rodi project. i call it a message collector.
in UDP protocol you can work completely connectionless. you send message, you get no response, but message collector keeps the message, checks signature, takes action if needed, etc. Port scan of the message collector is pointless because message collectr never responds to incoming packets.
Let; say that you are a great listener, but you do not like to talk much (not even TCP ack). you post a IP range on some messge boad (for example subnet 0.168.1.1, where first 0 is intentional). Only one (or very small number) of the IPs belong to you. your "subscribers" should send packet to all IPs in the subnet to reach you.
Size of the UDP packet is relatively small and subscribers do not create lot of traffic when send 256 (in example above) packets. Port scan can not be used to find oout the peer. Simultaneous DDoS attack against all IPs in the range is unlikey. The only way of action of a spammer try to choose one IP, ran attack against it for some time and see for any results (or lack of it). this solution takes time and unreliable.
In Rodi project peers use IP scan to find each other. Peer (Rodi host) posts IP mask and port number. Host check signature of the incoming packets and drops (or logs) unsigned packets. Host acks only correctly signed packets.
fact that a peer is a message collector can not be established
there is more on the Rodi User Manual pages. check the last part - General Q&A
hope it will help to the project
I can't see bouncers having much of a life, at least on the public internet.
Unless publisher "owns" or controls the bouncers. Think about network of people who attempt to solve a problem of data delivery. networks like Ant, Mute, Tor exist. in all of them people donate bandwidth. in Tor there 100s of dedicated proxys. i do not see reason for using Tor and not Rodi or both. sometimes people are driven not only by personal desires.
IP spoofing is a tough task. it is not easy to do it automatically in reliable way. i yet have to add code which allows to discover that IP spoofing possible for the node. the most important - IP spoofing is platform dependent. such automatic process it requires external server running 24/7 (think about privacy issues for this server, which require opennes of all server side code, all collected logs are known, etc.). only two weeks ago i did not have access to such server. Rodi project survives because of efforts and time of one person. i work, but the progress is slow.
message collector idea demonstrates one of possible applications for half duplex proxy. you can think about more applications. for example, resident in country where access to Internet is restricted still can receive messages from friends without advertising real IP address.
today there is no functional network i am aware of which allows "spaming" - sending messages to whole ISP subnet. all networks are TCP based and require "connection".
the same is search for the peer. In Rodi you need only port number and IP subnet and IP scan (no kidding here, real IP scan if your NAT can stand it) will do the rest. If you know how to sign the packet you will get ack. In Tor you need exact IP address and nothing else will work.
In your typical anonymous network you see clear header (pattern) in the IP packet. existing traffic shapers can easy filter out Skype or Filetopia. Rodi functional requirements (not implemented yet) assume that Rodi packets will spoof existing popular protocols, like VoIP to hide the nature of the traffic.
In many ways Rodi differs signficantly from other projects.
P.S. let's return to the problem of communication between an american spy in Russia and CIA. CIA should send messages to the spy and spy should send messages to CIA. assumng (unlikely) decision of CIA to use Rodi for the communication CIA can broadcast messages to 1000s of IPs where only one of IPs belong to the spy. for example, CIA can spam the whole ISP in Russia. spy can use public terminal to get the messages (spy never acks the message directly).
spy send messages to CIA using a chain (or tree) of bouncers preestablished and controlled by CIA. spy never knows that (s)he works for the CIA, because IP address of CIA is hidden.
it is similar to posting a message among ads in the dayly news paper.
anonymity of the transaction is based on the amount of the traffic running through the gateways/routers and complexity of the tracing of spoofed IP headers running through long chain of bouncers, where each bouncer can forward message to more than one IP.
this is one of the interestig catches here - bouncer does not neccessary know exact IP of the destination peer. bouncing rule contains
- incoming port (PI)
- destination IP subnet (DS)
- destination port (DP)
which reads "forward all packets arriving on port PI to all IPs in the subnet DS port DP". in the typical application CIA sends "GET DATA" request to the bouncer port, but the data itself can be sent directly.
probably no one of the existing peers employ any meanings of protection, but on the other hand probably one of them does. you never can be sure is it a bouncer and seed spoofing IP address or you talk directly with the seed without a bouncer on the way.
For example, scenario with two machines in the same campus LAN - one is a bouncer and the other is a publisher. And bouncer probably duplicates packets to many IPs and only one of them belongs to the publisher and publisher sends ack directly to the leacher spoofing IP of the bouncer. can be tricky to figure out what is going on without log of all IP headers on all participating gateways and routers.
there are two ways in the existing code to hide real identity. Using bouncers and spoofing IP. For spoofing IP in Java you will have to add dummy IP interface in your system. I am not sure does your connection allow IP spoofing, but we can run tests. IP spoof in LAN is always possible and can be interesting in some situation. Try this help http://rodi.sourceforge.net/helpRodi.html#Lesson%2 03
The other way to protect the connection is DSA signature. Rodi client can be configured to discard unsigned packets. Because Rodi is UDP based protocol and is completely connectionless typical IP port scan will not discover the Rodi node if Rodi client is configured to drop unsigned packets.
One of the possible applications is a message collector. Let's say that you are an extremely good listener. But you do not like to talk much. you can publish an IP range (not one IP, but a subnet containing 2 or more IP addresses). leachers looking for sensitive data send requests (see Rodi chat help) and you log the messages, but you never ack, because messages are not signed. This is what i call a message collector. If in 24 hours from the first request the data appears somewhere on the NET and can be found with regular search this is a pure coincidence. It can be extremely hard to follow all IP's and trace spoofed IP addresses.
Message collector does not have to have uplink, which is interesting in sense that this is probably first "half duplex" internet application. or message collector can send acks via a bouncer (with some delay) or spoof IP and send ack, and so on.
On one of the Rodi web pages (probably "general questions" section of the help) you will find following example. Imagine that you knock all doors on a street and ask for milk (you probably should use some well defined knock), but nobody opens the door and suddenly in one of the windows you see hand giving you a glass of milk. can you know what door exactly you have to knock to get that milk ? not really, because you have no idea what is going behind the doors (phone calls may be ?).... and not even by knocking one door and waiting some time, because such behaviour can be easily discovered and such customer blocked.
console (command shell) version requires only GNU Java
if you have GCC of reasonably fresh version check in README how to compile the source code and generate binary for your platform. compilation is fairly easy process - you just have to compile all java files in src directory and you are done.
to get GUI you indeed need rather new JRE. i think 1.4 will do the trick.
...Bearshare is apparently dead. they had to settle (30mil USD ?). Now iMesh (?) owns code base, trade name and all related domains. i think this is last widely used commercial p2p application. i expect that next step is going to be to attempt to remove all open source clients from the US servers.
what is interesting that both clients you mentioned use UDP as a transport, something that Bram Cohen hardly accepts even for client/tracker negotiation.
Rodi documentation sucks, that's true. mainly because of my English and partially because it was updated from time to time and now is inconsistent. Still it contains enough info to get a rough idea how the things work. The problem is that it requires more effort than it should to get through the docs.
i think that this is an exageration, that it will take a week to install java. two days ago i installed JDK on fedora server Core 2. btw you need much smaller JRE instead of JDK (15M vs. 45M).
On Linux download rmp.bin file from java.sun.com. on some systems you will need to execute script
export JAVA_HOME="/usr/java/jdk1.5.0_06/"
export JAVA_PATH="$JAVA_HOME"
export PATH="$PATH:$JAVA_HOME/bin"
Correct JAVA_HOME to point to the installed code and save it as a shell script file, for example java.sh. put the file to/etc/profile.d or in one of init scripts/etc/rcX.d
On Windows you get JRE installer which does all the work.
I never had access to OSX - i can't help you here, but Rodi works on Apple machines.
Java engine has both command line and GUI options. i use mainly command line interface to save RAM. GUI is bad, but allows to access main functionality. Command line provides extensive (i mean really extensive) debug info on what is going on with counters and logs in each and every corner.
the project was on slashadot. it is insanely hard to get into the slashdot news for an average guy and i failed to do, but one of the ZDNET bloggers posted about the project and some Slashdoter without even bothering to contact me or let me know decided to post "Is Rodi a Bittorrent replacement ?". Rodi was never ment as a replacement of BT btw. i witnessed ~10K of downloads in one day and as you can already guess was complitely unprepared for it. There was no reliable peers, etc.
then you will probably (not) find this project interesting http://www.gomyplace.com/ (click See Demo)
Back to Rodi - i would appreciate any feedback you can find time for. i am trying to make the application usable and i intend to continue the development. my e-mail latytet at yahoo dot com or you can post anonymously on the Rodi message board http://sourceforge.net/forum/forum.php?forum_id=49 6953
we can discuss issue of the bouncers. i think there is some misunderstanding about bouncers, because bouncers in no way are mandatory and in general case nothing prevents you from using chain of public bouncers like, for example, in Tor. Command line interface allows plenty of flexibility in how you use the client and what you do it with it. You can run similar to DC++ hub or implemenet small completely distributed (WASTE?) network of trusted peers
Java was a natural choise to bring prove of concept fast and get feedback from the users. unfortunately the feedback remains zero. among planned steps is implementation in C# (Mono) and small embeddable C/C++ agent
it allows to run a daemon on any PC (NATed, firewalled, whatever) and be able to access the file system, manage user accounts, etc. via regular internet browser. blog ? no problem. extend daemon by any bloggin software or run PHP based blog. gomyplace daemon will tunnel HTTP for you.
think about gomyplace as a easy way to run HTTP server. and gomyplace PROXY which caches the data (this one is optional) allows you to turn the host off and still you will be able access the data.
Re:One Point For Gmail
on
Gmail vs Pine
·
· Score: 1
...on top of it - i started a new porject (GPL, of course) which allows to access PC at home from any inernet enabled device or just using SMS and all this without openning any port in NAT.
check this out http://larytet.sourceforge.net/goMyPlace.shtml
this is still more or less non-exisitng with only localhost demo, but we make quick progress on the server side. this solution will allow to access text and HTML based services at about zero bandwidth and about zero RAM and CPU requirements. and yes, End-to-End encryption and "no Java" option.
small hack/patch in BC probably even without recompilation and tracker will never known that it is BC.
Trackers use counters willingly provided by the clients. Simple Azureus mod (and yes, may be i'll even do one to make things funny) would do the trick
if tracker owners want to control content distribution they should switch the protocol. Among alternatives - DC, Rodi, etc.
BT is NOT inteneded for what they are trying to do.
Slashdot Mirror
for example, it can make illegal smart caching like the one gomyplace reverse proxy uses
yes, selling volatility is an interesting approach to the problem, straightforward shorting is not bad too
anyway nothing bad happened, this is just a post, one among many have a nice day
Skype is not a public company. eBay is, but the stock performs so-so for some time already
i used XML file on some HTTP server to exchange IPs. actually not IPs but IP subnets. after that peers run IP scan to find each other
use openwengo instead - open source
Akamai serves businesses, goMyPlace allows access to the network cache for everyone .. and completely free of charge
Bram with Cachelogic trys to make money from commercial distributions. goMyPlace trys to provide service for regular peope like you and me.
in UDP protocol you can work completely connectionless. you send message, you get no response, but message collector keeps the message, checks signature, takes action if needed, etc. Port scan of the message collector is pointless because message collectr never responds to incoming packets.
Let; say that you are a great listener, but you do not like to talk much (not even TCP ack). you post a IP range on some messge boad (for example subnet 0.168.1.1, where first 0 is intentional). Only one (or very small number) of the IPs belong to you. your "subscribers" should send packet to all IPs in the subnet to reach you.
Size of the UDP packet is relatively small and subscribers do not create lot of traffic when send 256 (in example above) packets. Port scan can not be used to find oout the peer. Simultaneous DDoS attack against all IPs in the range is unlikey. The only way of action of a spammer try to choose one IP, ran attack against it for some time and see for any results (or lack of it). this solution takes time and unreliable.
In Rodi project peers use IP scan to find each other. Peer (Rodi host) posts IP mask and port number. Host check signature of the incoming packets and drops (or logs) unsigned packets. Host acks only correctly signed packets.
fact that a peer is a message collector can not be established
there is more on the Rodi User Manual pages. check the last part - General Q&A hope it will help to the project
regarding interesting tasks/job
my e-mail larytet at yahoo com
Unless publisher "owns" or controls the bouncers. Think about network of people who attempt to solve a problem of data delivery. networks like Ant, Mute, Tor exist. in all of them people donate bandwidth. in Tor there 100s of dedicated proxys. i do not see reason for using Tor and not Rodi or both. sometimes people are driven not only by personal desires.
IP spoofing is a tough task. it is not easy to do it automatically in reliable way. i yet have to add code which allows to discover that IP spoofing possible for the node. the most important - IP spoofing is platform dependent. such automatic process it requires external server running 24/7 (think about privacy issues for this server, which require opennes of all server side code, all collected logs are known, etc.). only two weeks ago i did not have access to such server. Rodi project survives because of efforts and time of one person. i work, but the progress is slow.
message collector idea demonstrates one of possible applications for half duplex proxy. you can think about more applications. for example, resident in country where access to Internet is restricted still can receive messages from friends without advertising real IP address.
today there is no functional network i am aware of which allows "spaming" - sending messages to whole ISP subnet. all networks are TCP based and require "connection".
the same is search for the peer. In Rodi you need only port number and IP subnet and IP scan (no kidding here, real IP scan if your NAT can stand it) will do the rest. If you know how to sign the packet you will get ack. In Tor you need exact IP address and nothing else will work.
In your typical anonymous network you see clear header (pattern) in the IP packet. existing traffic shapers can easy filter out Skype or Filetopia. Rodi functional requirements (not implemented yet) assume that Rodi packets will spoof existing popular protocols, like VoIP to hide the nature of the traffic.
In many ways Rodi differs signficantly from other projects.
spy send messages to CIA using a chain (or tree) of bouncers preestablished and controlled by CIA. spy never knows that (s)he works for the CIA, because IP address of CIA is hidden.
it is similar to posting a message among ads in the dayly news paper.
anonymity of the transaction is based on the amount of the traffic running through the gateways/routers and complexity of the tracing of spoofed IP headers running through long chain of bouncers, where each bouncer can forward message to more than one IP.
this is one of the interestig catches here - bouncer does not neccessary know exact IP of the destination peer. bouncing rule contains
- incoming port (PI)
- destination IP subnet (DS)
- destination port (DP)
which reads "forward all packets arriving on port PI to all IPs in the subnet DS port DP". in the typical application CIA sends "GET DATA" request to the bouncer port, but the data itself can be sent directly.
For example, scenario with two machines in the same campus LAN - one is a bouncer and the other is a publisher. And bouncer probably duplicates packets to many IPs and only one of them belongs to the publisher and publisher sends ack directly to the leacher spoofing IP of the bouncer. can be tricky to figure out what is going on without log of all IP headers on all participating gateways and routers.
there are two ways in the existing code to hide real identity. Using bouncers and spoofing IP. For spoofing IP in Java you will have to add dummy IP interface in your system. I am not sure does your connection allow IP spoofing, but we can run tests. IP spoof in LAN is always possible and can be interesting in some situation. Try this help http://rodi.sourceforge.net/helpRodi.html#Lesson%2 03
The other way to protect the connection is DSA signature. Rodi client can be configured to discard unsigned packets. Because Rodi is UDP based protocol and is completely connectionless typical IP port scan will not discover the Rodi node if Rodi client is configured to drop unsigned packets.
One of the possible applications is a message collector. Let's say that you are an extremely good listener. But you do not like to talk much. you can publish an IP range (not one IP, but a subnet containing 2 or more IP addresses). leachers looking for sensitive data send requests (see Rodi chat help) and you log the messages, but you never ack, because messages are not signed. This is what i call a message collector. If in 24 hours from the first request the data appears somewhere on the NET and can be found with regular search this is a pure coincidence. It can be extremely hard to follow all IP's and trace spoofed IP addresses.
Message collector does not have to have uplink, which is interesting in sense that this is probably first "half duplex" internet application. or message collector can send acks via a bouncer (with some delay) or spoof IP and send ack, and so on.
On one of the Rodi web pages (probably "general questions" section of the help) you will find following example. Imagine that you knock all doors on a street and ask for milk (you probably should use some well defined knock), but nobody opens the door and suddenly in one of the windows you see hand giving you a glass of milk. can you know what door exactly you have to knock to get that milk ? not really, because you have no idea what is going behind the doors (phone calls may be ?). ... and not even by knocking one door and waiting some time, because such behaviour can be easily discovered and such customer blocked.
i appreciate your efforts and time, i really do
gcj --main=rodi.Start -g -o rodi.bin rodi/*.java rodi/chat/*.java rodi/dt/*.java rodi/dt/naive/*.java rodi/mng/*.java rodi/msg/*.java rodi/parser/*.java rodi/rm/*.java rodi/util/*.java rodi/xml/*.java
It will give you console only, no GUI version.
console (command shell) version requires only GNU Java if you have GCC of reasonably fresh version check in README how to compile the source code and generate binary for your platform. compilation is fairly easy process - you just have to compile all java files in src directory and you are done. to get GUI you indeed need rather new JRE. i think 1.4 will do the trick.
what is interesting that both clients you mentioned use UDP as a transport, something that Bram Cohen hardly accepts even for client/tracker negotiation.
On Linux download rmp.bin file from java.sun.com. on some systems you will need to execute script /etc/profile.d or in one of init scripts /etc/rcX.d
export JAVA_HOME="/usr/java/jdk1.5.0_06/"
export JAVA_PATH="$JAVA_HOME"
export PATH="$PATH:$JAVA_HOME/bin"
Correct JAVA_HOME to point to the installed code and save it as a shell script file, for example java.sh. put the file to
On Windows you get JRE installer which does all the work.
I never had access to OSX - i can't help you here, but Rodi works on Apple machines.
Java engine has both command line and GUI options. i use mainly command line interface to save RAM. GUI is bad, but allows to access main functionality. Command line provides extensive (i mean really extensive) debug info on what is going on with counters and logs in each and every corner.
the project was on slashadot. it is insanely hard to get into the slashdot news for an average guy and i failed to do, but one of the ZDNET bloggers posted about the project and some Slashdoter without even bothering to contact me or let me know decided to post "Is Rodi a Bittorrent replacement ?". Rodi was never ment as a replacement of BT btw. i witnessed ~10K of downloads in one day and as you can already guess was complitely unprepared for it. There was no reliable peers, etc.
Back to Rodi - i would appreciate any feedback you can find time for. i am trying to make the application usable and i intend to continue the development. my e-mail latytet at yahoo dot com or you can post anonymously on the Rodi message board http://sourceforge.net/forum/forum.php?forum_id=49 6953
we can discuss issue of the bouncers. i think there is some misunderstanding about bouncers, because bouncers in no way are mandatory and in general case nothing prevents you from using chain of public bouncers like, for example, in Tor. Command line interface allows plenty of flexibility in how you use the client and what you do it with it. You can run similar to DC++ hub or implemenet small completely distributed (WASTE?) network of trusted peers
Java was a natural choise to bring prove of concept fast and get feedback from the users. unfortunately the feedback remains zero. among planned steps is implementation in C# (Mono) and small embeddable C/C++ agent
and this is exactly how data transfer layer works in my Rody project. google Rodi P2P
it allows to run a daemon on any PC (NATed, firewalled, whatever) and be able to access the file system, manage user accounts, etc. via regular internet browser. blog ? no problem. extend daemon by any bloggin software or run PHP based blog. gomyplace daemon will tunnel HTTP for you.
think about gomyplace as a easy way to run HTTP server. and gomyplace PROXY which caches the data (this one is optional) allows you to turn the host off and still you will be able access the data.
gomyplace.com will eventually do all this without Java ..and open source, of course
"ikea" is not that great
http://gomyplace.com/Code%20Monkey.mp3
this is still more or less non-exisitng with only localhost demo, but we make quick progress on the server side. this solution will allow to access text and HTML based services at about zero bandwidth and about zero RAM and CPU requirements. and yes, End-to-End encryption and "no Java" option.
small hack/patch in BC probably even without recompilation and tracker will never known that it is BC.
Trackers use counters willingly provided by the clients. Simple Azureus mod (and yes, may be i'll even do one to make things funny) would do the trick
if tracker owners want to control content distribution they should switch the protocol. Among alternatives - DC, Rodi, etc. BT is NOT inteneded for what they are trying to do.