Contents
- Frequently Asked Questions
- What is BCWJxta?
- Independent of network protocols and topologies?
- You say "users can communicate". That sounds nice. It's good when users communicate. What does that mean though?
- If it can do the same sort of stuff that the web can, why reinvent the wheel? Why not just make BCWNS web content, and skip the p2p thing?
- Ok, so p2p. Why Jxta rather than, say, Bittorrent? Gnutella? Etc?
- So we should use BCWJxta for slicing, dicing, baking muffins, and babysitting our children from now on?
- I want to help out with BCWJxta. What stuff is currently broken or yet to be done?
Frequently Asked Questions
What is BCWJxta?
BCWJxta is a peer-to-peer networking system, built using Sun Microsystem's Jxta project, that allows users to communicate independent of network protocols and network topologies. Public Key Cryptography is used both to allow secure communication, and to allow the users to be sure of who they're talking to (using signatures).
Independent of network protocols and topologies?
Yes : BCWJxta nodes are identified with a variety of protocol-independent and topology-independent information, including a globally unique identifier (GUID). Route information is determined dynamically, allowing a node to be using one protocol at one point (eg, tcp/ip), and switch to another protocol (eg, udp) and communication can still continue essentially uninterrupted (assuming a path continues to exist between them).
You say "users can communicate". That sounds nice. It's good when users communicate. What does that mean though?
Good question. Also a hard question because there's no simple answer to it. The reason is, there's a wide variety of things that users can do with respect to communication. You could play chess with a friend, or download content (like music), or talk in a forum with members of your local community, or order pizza from a business that has an ordering service available, or bid in an auction similar to ebay but not reliant on big central servers. Basically, if you can do something on the current "web", the potential exists to do it over BCWJxta too.
If it can do the same sort of stuff that the web can, why reinvent the wheel? Why not just make BCWNS web content, and skip the p2p thing?
The current web, as a mostly html or xhtml creature, is good for static content presentation, or even dynamic "database-derived" content, but has limited ability to deal with truly interactive situations. Sure, the user can fill out forms and submit data. The user can even participate in stuff like IRC channels if the web application does something like frequent polling. But, where the web has interactivity "tacked on", and often painful, BCWJxta is designed from the ground up to support dynamic interactivity. If you're using a web application and you move from your laptop (using a cable modem connection) to your PDA (using wifi) resulting in completely different addresses and most likely different routes, the web application will almost certainly require you to start a fresh session. BCWJxta (assuming you still have a route available), would simply carry on -- the node you're talking to won't necessarily even know that anything's different.
Ok, so p2p. Why Jxta rather than, say, Bittorrent? Gnutella? Etc?
Bittorrent, and Gnutella, as far as I know, are tcp/ip only (single network protocol). Feel free to email me if I'm wrong. If you know of a different p2p technology that can hop between protocols let me know : I'd love to look at it (Jxta hasn't been entirely free of headaches for me).
<Is there anything about BCWJxta that makes it particularly suited to wireless, as opposed to being just a general approach to interactivity and dynamic content?>
Yes. P2p and wireless have many of the same characteristics, thus being well suited for each other.
In a p2p network, users join up and leave fairly frequently, so the system has to be able to continue to function given that it's not sure who will be around, when, and for how long. In a wireless network, nodes appear and disappear in similar fashion (due partly to signal strength varying, users moving around physically, and users signing off/terminating connection). So both systems need robust, dynamic path calculation.
In a p2p network, you can have very few users sometimes, or surges of very large numbers of users at other times, and you can't generally predict how many people will use the system at a given time. In a wireless network, you can't be sure how many nodes will be linked up with each other, due to users moving around, signing on/off, etc. So both systems need to consider scalability carefully.
In a p2p network, it's generally a bad idea to use the "centralized server" model, partly because it's less reliable and scaleable and partly because it limits spontaneity between individual nodes. In a wireless network, it tends to be a bad idea because you can't be sure that all the nodes can even reach the centralized server (all nodes can not necessarily reach all other nodes). So both p2p and wireless benefit from decentralizing processing and logic as much as possible.
So we should use BCWJxta for slicing, dicing, baking muffins, and babysitting our children from now on?
Well no, there's some scenarios where BCWJxta isn't best. In situations where you're able to use a fixed, reliable, high speed path, it's best to do so. BCWJxta jumps through many hoops to try to make sure your traffic goes where it's supposed to go, but BCWJxta expects that it will run on a variable, unreliable, unknown speed path, and thus your data traffic has a chance of just vanishing in to the wires. Use BCWJxta to try to achieve the best results in a noisy, chaotic, ever-changing environment. You're probably best with something else if you're already in an environment where things are already reliable.
I want to help out with BCWJxta. What stuff is currently broken or yet to be done?
1) Cryptography is currently semi-broken. This doesn't mean that BCWJxta sometimes reveals user data to everyone who's listening. What it means is that BCWJxta sometimes sends complete gibberish : completely secure but completely useless too.
2) Testing using the chess playing system (computer versus computer) has revealed that BCWJxta pipes are timing out/failing at indeterminate intervals. Sometimes the computers will get through a full game. Sometimes they won't. We're not sure why this is, and we'd like to find out.
3) More applications == good. Right now, we have a trivial little chat program, a chess playing interface, a traffic data aggregator, and a really simple file transfer protocol (no commands, just raw file dump essentially). We'd like BCWJxta to be Made Better by more stuff being written to use it. More games would be cool.. perhaps Jabber Over Jxta, for instant messaging.
4) It would be good to integrate JUnit tests in to the BCWFramework. I started on this but haven't got very far to date.
5) Semantic web == good. Right now, the system communicates in an application-specific manner.. a specific request for a specific service, along with service-specific message passing. Even though BCWJxta already communicates in XML, it's using a bunch of narrow (extremely narrow) vocabularies right now. I'd much prefer an rdf/owl data transfer approach so that various different applications can drink from the well of knowledge without having to explicitly know the meaning of a bunch of proprietary message bundles.
