GPA
January 8th, 2003, 12:11 AM
Anyone here able to help for the imposiable?
I got this proggie but I want to use it on more than one PC on the network, any idea about how the ports are gonna be set in my router? I though maybe open 41170 to one pc, and then 41171 to the other, then on that pc redirect 41171 to local 41170, might work. Any other ideas?
Hope this can get some others connected, or some other ideas that come up that might be able to help.
-GPA
MoonMan
January 8th, 2003, 12:51 AM
Ok this is taken directly from Blubster.net forums (as we all know, Piolet is the next of kin from Blubster). Since Piolet and Blubster are so alike (besides the various bug fixes) I thought this might help you (since there is not much help for the program yet, because it is so new). I would try to write it in my own words but in the end it would be plagerism. I'll just post the whole article:
Client documentation: Blubster, Connecting to the network.
Blubster is getting too much connection problems for too much users. The main reason is the transport protocol, UDP.
I'll try to explain why connecting with blubster is so difficult for some users, I'll put some solutions for the problems and I'll explain what are we exactly doing for enabling the 100% of the users to connect to the network with the next version, planed to be released in the first week of february.
Our loved protocol ("MANOLITO") is built on the top of UDP. UDP provides an excellent platform for our network, because it is anonymous and unreliable. Our network is much healthy than Gnutella in part because UDP is much better for message based protocols.
The problem resides in the fact that UDP transmissions need both computers to be enabled to open ports for inbound connections. The Blubster client uses the UDP protocol port number 41170 for receiving data from other clients. If your client can’t listen that port, it will not be able to communicate with other clients, and you’ll be offline after all.
There are many reasons for this to happen. For example, if you are behind a firewall that blocks all ports by default, you’ll need to configure it for the desired UDP port 41170. Other firewalls -like zonealarm- can’t open any ports, so you’ll need to enable the server rights to the Blubster program, or set the security level to a point that enables programs to listen UDP ports. Other firewalls -like windows XP built in- simply disable all UDP communications, so you’ll need to disable the entire firewall in order to use Blubster.
Router users are having a lot of problems to connect with Blubster. This is because when a remote computer sends some data to the UDP port 41170, it arrives to the router, but the router may not be forwarding the data to the computer correctly. Your router will have an IP address, visible to the internet, where all the external data is sent. Your router should then resend this data to the computer -which has another different and private IP- so that your Blubster client can listen to other clients.
What you need to connect to the Blubster network through a router is configuring the Port Forwarding. The configuration steps may vary from a router to other, but the basis is that DATA RECEIVED TO THE PORT 41170 USING THE PROTOCOL UDP MUST BE FORWARDED TO THE IP OF THE COMPUTER RUNNING THE BLUBSTER CLIENT. Some users needed to forward ports from 41170 to 41350.
Maybe it will be necessary to configure your public IP in your Blubster client. In the configuration window of blubster, type your public IP -the IP of your connection which is visible on the internet- in the field “Force Local IP Address”. This helps when your IP is static, which is the normal for router users. Modem users don’t have much problems connecting - as far as I know.
Another thing that can be stopping Blubster is Internet Connection Sharing, ICS. This software is used to share an only internet access to several intranet computers. Unlucky ICS doesn’t handle well UDP transmissions that Blubster needs to perform. ICS and Blubster are incompatible.
The Blubster network is now small but stable. It is much more efficient and scalable than any other peer-to-peer network, and we are decided to bring this great thing to the highest possible number of persons. The UDP usage is the key that will open the TRUE DECENTRALISATION. Using complex techniques -outbound of this document- of broadcasting and multicasting over the UDP protocol, MANOLITO means a breakthrough for the peer-to-peer technology, because no other protocol is designed to be absolutely autonomous.
It seems to be clear that the base of the network will be on that way, because the soul of the network needs UDP.
How are we going to enable everybody to connect with Blubster if they can’t use UDP? The answer is “Guide Nodes”. Guide nodes will be normal Blubster peers that will be acting like a guide for non-UDP-enabled peers.
The idea is that, when a peer (peer-A) that can’t use UDP tries to connect, it will “ask” for a UDP-enabled peer (peer-B) to be his/her gateway to the network. A normal TCP/IP connection is now between the two peers. The peer-A will see through peer-B. When peer-A needs to search for something, it passes the search to peer-B, who will process it, resending it -using the normal UDP transmissions- to the network. Peer-B will then receive the results and will forward them to peer-A. This is similar to the router port forwarding, but we will do it in a different layer.
The pros for this method are that everybody will be able to connect with Blubster. If you can navigate the web then you can connect to a Guide Node. The cons are the TCP/IP connection needed. TCP/IP transmissions are reliable, which means that guided peers will not be anonymous. Guide Nodes will sacrifice about 20% of performance receiving, processing and sending data to the guided peer.
We are now doing tests for Guide Nodes, and the results are very good. Our focus in that moment is in getting better performance and implementing a strong encryption for that TCP/IP communication, in order to save the anonymity at an acceptable level.