the power of broadcast
[a revolution in mass-scale content distribution]
Difference (from prior minor revision) (major diff, author diff)
frequently asked questions
what's with kast's web-based user interface?
to our knowledge, kast is the only existing file sharing app that runs on all modern computer platforms, requires no additional software to be downloaded or installed, has a graphical user interface, and was not written using java. Other non-java apps may "work" on several platforms, assuming that you download and install a user interface library first. On the other hand, almost everyone already has a web browser installed.
Some users still prefer text-based user interfaces in a terminal window. kast is also the only file sharing app with a graphical interface that also works automatically in a terminal window (by using a terminal-based web browsers such as lynx).
what was lost by using a web-based user interface? In the case of kast, almost nothing was lost. Web-based interfaces are certainly not appropriate for applications that have real-time dynamic displays, such as 3D modelers. In fact, a purely web-based interface would not even be appropriate for something as non-dynamic as a word processor. However, file sharing applications have some of the least dynamic interfaces of all (with forms for searching, and lists of results, etc.) Thus, web-based user interfaces are perfect for file sharing apps.
the upshot of all this is that the kast user interface works on almost everyone's computer platform. Portability was the main concern here, but web-based user interfaces have several additional advantages: smaller application size--- for almost all platforms (except for MacOSX), the kast distribution fits easily onto a single floppy disk; the small size of the web-based interface code is partially to thank for this. no user interface learning curve--- anyone who is familiar with using the web will have no trouble using kast. skinnable user interface--- the layout of the user interface is in html files that are completely separate from the kast application. The look and feel of kast can be modified completely without even restarting--let alone recompiling--kast. skins are easy to create--- anyone who has written html for a web page is capable of creating a kast skin. easily integrated with the web--- links from web pages can allow users to easily manipulate their kast node, and kast broadcasts can contain content that points back out at the web. For example, if you have your kast node running, you can click to see your catcher or your received folders.
why weren't konspire2b and kast written using java?
for a platform-independent network system like konspire2b, many people would think that java is an obvious choice. People who generally oppose the use of java often do so because java is slow. The speed issue was only a minor factor in our choice to avoid java. Major factors were: java applications are difficult to install--- many users do not already have a copy of the java virtual machine installed on their machine. For these users, installing a java application means downloading and installing the java runtime, which is quite large and can be difficult to configure.
java applications start up slowly--- even the smallest java applications can take several seconds to start up, since the virtual machine needs to be loaded first.
java applications have slow, unresponsive user interfaces--- on slower machines, using java-based user interfaces can be frustrating (resizing the application window can mean taking a coffee break). java applications use a lot of memory--- on most platforms, the virtual machine itself requires several MiB of memory, even for small applications that use very little memory. For more complicated applications, such as konspire2b, the virtual machine adds a lot of memory overhead. For example, kast currently uses about 1 MiB of memory when it's up and running. konspire 1.0 server (written using java) uses about 12 MiB. The interesting point is that konspire2b is far more complex that konspire 1.0 server (for example, the server portion of konspire 1.0 doesn't even have a user interface).
java applications leak memory--- java uses garbage collection to manage memory, which seems to imply that programmers don't need to think about memory management at all. However, garbage collection gives a false sense of security, and java applications can still have memory leaks unless programmers are very careful. In fact, many java applications that run for extended periods of time leak memory to the point of exhausting all system memory. These types of leaks are very difficult for programmers to isolate. In fact, memory management may be more difficult with a garbage collector than without one.
even Sun, the company that created Java, has encountered many of these issues when trying to use Java for internal development. See this memo for more information.
what does the green "+" character in the far left column of the catcher denote?
it indicates that your node "wanted" that broadcast. The "+" essentially means that you were subscribed to that channel AND that you had not received the broadcast yet AND that the signature on the prebroadcast was correct (if you have a key for that channel).
for example, you might see three copies of a prebroadcast with green + next to them, and then two more prebroadcasts without green +'s. That means that three prebroadcasts went out on the network before you finally received the broadcast, and that two more went out after you received the broadcast. Your node wanted broadcast described by the first three prebroadcasts, but no longer wanted the broadcast when the last two prebroadcasts were sent (since it already had the broadcast by then). i have posted my channel key on my website, and receivers have downloaded it.
They see my prebroadcasts in their catcher, but they are not getting my files. What's wrong?
if many receivers have complained about not receiving your broadcasts, firewall problems are not likely. You may have mixed up your sender and receiver keys. You need to give your receivers the key from your receiver_keys folder, not from your sender_keys folder. If you discover that you have made this kind of mistake, it would be best if you started over and generated new keys, since the sender key for your channel is no longer private.
if only one receiver is missing your broadcasts, he or she may be behind a firewall without a tunnel for kast (see this question for more information). how do I send a series of files out on the same channel?
kast supports sending a series of files out on the same channel with minimal effort on the part of the sender. To send a broadcast series, select a folder with the file browsing interface. kast will send all files in the folder out on the channel one-by-one, attaching the same comment to each file.
note that sub-folders of the selected folder are not included in a broadcast series.
how do I view kast's web user interface from a remote machine?
kast comes configured to only allow web connections from the local machine that it is running on. To connect to your kast node with a web browser running on a remote machine, you need to add the address of the remote machine to the file "allowedWebHosts.ini" in the "settings" folder. Add the remote machine's address on a new line (after localhost) in allowedWebHosts.ini.
to allow web connections from a range of addresses, add the address prefix to allowedWebHosts.ini. For example, adding 192.168 to allowedWebHosts.ini would allow any machine to connect that has an address starting with 192.168 (192.168.1.1, 192.168.243.133, etc.). Only prefixes are supported---do not try to use "*" wildcards (for example, 192.168.* will not match anything).
keep in mind that accessing kast's user interface from a remote machine poses a security risk. If an attacker is sniffing on your network, he or she may be able to capture the commands you send to kast with your web browser. This would be a problem if you were generating key files remotely, since the attacker would be able to get your random seed, which would allow the attacker to re-generate your sender key and then pretend to be you.
accessing your kast node locally (to generate keys or otherwise) is completely secure, since none of your commands travel through the network.
the take-home message here is essentially: do not generate keys while you are connected to you kast node remotely.
does kast work from behind a firewall?
if your firewall administrator is willing to create a firewall tunnel for your kast node, then kast will function perfectly well (see this question for more information).
if you are behind a firewall that is managed by an adversarial administrator, however, your kast node will have only limited functionality. The bottom line is that your kast node will be able to connect to the network, receive/forward prebroadcast announcements, and initiate broadcasts, but it will not be able to receive broadcasts. Note that this behavior, like most konspire2b behavior, is the opposite of what occurs with other peer-to-peer software (with which you can download from behind a firewall, but you cannot host content).
during a broadcast, content is actively transmitted from the nodes that have the content to the nodes that do not. If your node wants a particular broadcast, the sending node will try to connect to your node to transmit the broadcast, but this connection will be blocked by your firewall. However, from behind a firewall, you can make outbound connections without being blocked. Thus, if you are on the sending end of a broadcast, your kast node will work fine.
how do I configure my Linux firewall with IPCHAINS to make it work?
This is just a case example of a configured Linux Router to do Masquerading. In this example the internet is connected to eth0 of the Linux machine (for example connected to a cable modem). The internal machine on which I want to run konspire runs on internal IP adres 192.168.0.4 In this case you have to add this line to your IPCHAINS rule:
ipchains -A input -i eth0 -p tcp --sport 110 --dport 6085:6085 -j REDIRECT --destination 192.168.0.4
ipchains -A input -i eth0 -p udp --sport 110 --dport 6085:6085 -j REDIRECT --destination 192.168.0.4
Don't forget to change 192.168.0.4 to the relevant internal IP adress of the machine you want to run Konsiper.
i am behind a firewall, but a tunnel has been set up for my kast node. What else do i need to do?
in most cases, you will not need to do anything else. kast comes configured to get your external address (in other words, the address of your firewall) by automatically querying a remote web script. Other nodes in the network will be able to make inbound connections to you using this address, and the firewall will pass these connections to your node through the tunnel that has been set up.
in some situations, however, the web script may not provide you with a proper external address. kast also allows you to manually set your external address. Before trying to set an address, you should disable the use of a web script (the address returned by the web script overrides whatever address you set). In the "settings" panel, set the address verification URL to a blank value . More details about manually setting your external address are given below.
you need to give your kast node an reachable external address to use. In general, this is the address of the firewall. In the "settings" panel of the user interface, enter the address of your firewall as the external address. You may need to obtain this address information from your firewall administrator.
if your kast node is running, you can click here to access your settings panel.
if you are behind a firewall, your machine uses a "fake" internal address that is not valid on the internet at large. Your firewall has a valid external address, however. When your kast node tells other nodes about itself (for example, when it connects to a katcher node), it must use the external address so that other nodes can connect to it. This kind of external inbound connection is crucial for receiving broadcasts.