I'm a relatively novice programmer and newish to java, and I've been tasked with creating a distributed system that runs two types of applications; a single 'Server/Router' and as many Client-Server 'Nodes' as desired.
-The Server/Router will maintain a table of client connection info
-The Nodes will each send connection info when they spawn
-The Node A can request File F from Node B
---This Request is sent to the router, which looks up connection info for B and sends a request for F
---B begins streaming F to the router, which in turn streams F to A
That's the general idea. It sounds like it would be fairly simple if it weren't for the fact that I've never done ANY distributed computing before... So my question isn't one of how to correct code, but whether my design will work (and if it will not, how I might correct it)
So my idea is to create a public class AVRouter, another class AVNodeInfo, and a third class ConnectionMap; AVRouter will have a collection of AVRouterInfo objects which contain a name, port number, and IP address for each node. It will also have a Queue of ConnectionMap objects, which I'll get to shortly.
AVRouter will have a ServerSocket dedicated to receiving connection info from Nodes when they start up and populating its AVNodeInfo table with said data. It will have another port for file requests; it will use the connection info for the requester and the responder to generate a ConnectionMap object, which it will add the the queue.
The idea being that while there are ConnectionMaps in the queue, it will use the first one to facilitate a transfer.
The last class, AVNode, is much simpler; on spawning it sends its info to the Router, and then it waits for user input to name another node and a file it wishes to request from that node. It will send a completed request to the Router when one is available.
Logic for handling the AVNodeInfo table will probably just be handled with timeouts-if it's been X time since a node has made a request, the node will terminate on its own and the table will delete it from the table on its own... this is a small-scale proof-of-concept type project so it's not really within to scope to handle this nitty-gritty just yet.
So I actually have two questions:
1) Will this design be fine, or should it be improved?
2) How exactly does one handle streaming data from source A through router B to destination C without actually complete transferring from A to B, then from B to C?
I hope this question is within StackOverflow's scope; I know it's design rather than code, but I believe it's specific enough.
The principal concept sounds very ok and is probably the most easy to implement (with the least pitfalls). Its practically a standard approach.
You might want to consider, instead of sending a file from node to server and then forward to the requesting node, to have the nodes connect directly with each other. Node A would just ask the server where is file F and then connect directly to node B. (that should reduce network load, since data travels a shorter route). But it adds quite some complexity (each node must be able to reach any other node and that makes each node a server). A composite approach would be to try direct connection and if that fails fall back to the via-server method.
You can just implement your original concept and when you have it working, see if you want/need that extension.
Edit: I would probably fuse NodeInfo and Connection (connection as a member of NodeInfo) - the server should have exactly one connection to each node (or if using multiple connections, have NodeInfo hold a collection of the open connections to that specific node).
EDIT: To add to the workability of your concept. Its generally what P2P sharing programs like BitTorrent implement. The "Tracker" acts as the initial "Router" telling each client about other peers. Peers then use direct connections to talk to each other. So its practical identical to what you've come up with, only there is not data traffic using the Server/Router as a bridge (for obvious bandwidth concerns, and it would contradict the P2P idea).