Updates
 
 
 

Final week: ending Tuesday 03-16
 
  Last week:
  Goals for this week:
  • Integrate the file transfer system. Using either:
    • The currently existing FTM which would require the simple integration of an agreement message between the two hosts before the transfer is initiated.
    • A modified version of the FTM that would run as a server on a known port and transfer incomming connections to seperate threads. The general insecurity here (openly accepting incomming files that can later be retrived,) make this a bad choice
    • Write a one.world file transfer manager that would inport the mp3 file as tuples and then send the tuples. The cost of reading the file into the tuple store (low compared to the cost of transfer) and the complexity of dealing with unordered tuples at the reciever make this solution somewhat unattractive.
  • Finish up the NetworkManager interface including all event tuples and QueryManager interface. Coordinating with Chia-yang on that last one.
  • Pass some network update events.
  • Write the election managing code.
  • Get preferences state from the UI preferences.
  • Finish everything
  • Start writing a paper
  • x
  Time spent:
  • 3-8: 3.5 hours: Reviewing existing one.world quero code and familiarizing myself with the UI integration. Trying to forsee potential difficulties.
  • 3-9: 0.5 hours: Went over Final Report comments.
  • 3-9: 4 hours: Wrote a good chunk of the FileTransfer component, integrating it to pass messages from Quero to the existing FileTransferManager code.
  • 3-10: 5 hours: Finished the TransferManager code, now it just needs to be cleaned. Also added file transfer stopping to the FileTransferManger and tested it (outside of the component.)
  Comments:
  • Debugged some problems with the DirChooser, where a JComboBox for the possible root folders was having it's index set to 1. In *nix there is only the / directory, so the index needs to be 0.
  • Ran into some difficulties debugging when I tried to stop quero from the shell while the FileScanner was recursively scanning my HD (and taking forever, maybe I have a few symbolic links causing loops? !@#!). After stopping it I couldn't mk a new one, one.world would just hang on some processing.
  • Writing code in one.world is significanly easier now that certain concepts hav gained seperation in my mind. I spend more time coding and using the javadoc as a resource instead of just wading thourough it getting lost and evenually bogged down.
  • I'm also wishing that we had agreed on some sort of source control earlier on...
 

Week 5: ending Tuesday 03-06
 
  Last week:
  • Wrote out all the interface code for the NetworkManager
  Goals for this week:
  • Finish up the NetworkManager interface including all event tuples and QueryManager interface. Coordinating with Chia-yang on that last one.
  • Pass some network update events.
  • Write the election managing code.
  • Get preferences state from the UI preferences.
  • Finish everything
  • Start writing a paper
  • x
  Time spent:
  • 2-28: 1 hour talking with Bret, we rough sketched a workable solution for inserting nodes into the network as they try to login. Basically it's going to follow B tree rules which will use bandwith as a limitation on the number of children each node has (or some hardcoded limit if that works better.)
  Comments:
  • Basically because Bret doesn't have any other classes he's kept a write lock on the NetworkManager code while I finish up an OS project. I've basically just been keeping up with what's going on through email.
  • I also spent quite a bit of time building a new cage for my pet lizzard. His old cage was too small and didn't provide enough ventalation and he was dying.
  Goals for next week:
  • Make discovery work for us.
  • Get a basic searchable tree working for Chia-Yang to test his queries with
  • Get a small scale version of elections working, so we can demo a node dropping out.
  • Get some file transfers working, either with Tuples or the FTM.
 

Week 4: ending Tuesday 02-27
 
  Last week:
  • Went over Qeuero code and started getting a hang of remote events.
  Goals for this week:
  • Get Quero up and running and ideally two nodes discovering eachother and passing some messages.
  • Get a basic discovery service working. First at least be able to specify an IP for a node to link up with and join a simple network. Then add a naive discovery service using multicast with an incrementing TTL field.
  • Design and implement the state that the NetworkManager will need for the network structure.
  • Set up some remote event handler importing and exporting. Define the useful message types.
  • If there's any time left after all of this (and a big project for Gribble, and a Math midterm) hook up some of the UI controls to make for easier testing.
  Time spent:
  • 02-22: 2 hours: Drew some pictures of the current component layout. Just getting things down on some actuall paper in front of me helped quite a bit in desiging the component interfaces required for the network manager. (basically talks to the environment, quero main, the QueryManager and a timer.
  • 02-27: 4.5 hours: Wrote all the framework for the descriptors and handlers that the NetworkManager will need. Started writing classes to hold the network state.
  Comments:
  • Got bogged down this week with homework, a midterm, and espically an OS project. (And sleeping because everyone I know is sick and if I don't sleep I'll be sick and then I'll be ... Anyway next week is looking like I'll have a lot more time compaired to this one so I'm hoping to get some serious coding done.
  • I sat down last night and wrote a bunch of code until 3:30. I was sad to have to go to bed because things seemed to be falling into place. I think I had coders block up until about then and was having problems overcomming the learning/understanding threshold. But I think that's over now. (I'm actually looking forward to getting back to work asap.)
  Goals for next week:
  • Finish up the NetworkManager interface including all event tuples and QueryManager interface. Coordinating with Chia-yang on that last one.
  • Pass some network update events.
  • Write the election managing code.
  • Get preferences state from the UI preferences.
 

Week 3: ending Tuesday 02-20
 
  Last week:
  • Set up, and began experimenting with, one.world (damn I'm way behind!)
  Goals for this week:
  • Learn everything about one.world required to build our application
  • Review existing one.world code.
  • Spec out and finish coding a big chunk of the NetworkManager
  Time spent:
  • 02-13: 2 hours: Talked with Chia-yang on the phone. He helped me set up his existing quero one.world code and get the environement running. Saved a lot of time over having to figure it out
  • 02-13: 2 horus: Built this page and filled it out. Now I have html I can actually edit.
  • 02-18: 3 hours: Didn't have as much time to work on this as I'd hoped. I had to go through the tutorial again while looking at the code that Chia-yang sent me the other day so that I could get a better idea of what's going on. Also installed StarOffice on my Linux box, pretty cool, now I can read Word and PowerPoint docs all with a familiar UI ripped off from Windoze.
  • 02-19: 5 hours: Continued going over useful parts of one.world, like REP and Structured I/O. Wrote out a design overview of services and functionality that the NetworkManager will need to implement. Got sidetracked reading about the Class class and reflection in Java, so now I understand why descriptors take a Class[ ] as an argument, time well spent.
  Comments:
  • There were some confusing parts about setting up and running one.world.Main. Main problem was that I didn't have my current directory in may CLASSPATH so I couldn't "mk quero quero.Quero". Got that fixed and the environment built and things went pretty smoothly. Now just coordinating the source code without source control, maintaining a Forte project, and a one.world environment, should provide plenty of entertainment.
  • The meeting today (02-07) was pretty grimm. The one.world side of our project is looking pretty bleak. But I'm quite confident that we can get a minimal demo version going with some leaway for testing and enhancement (and writing a paper.)
  • Also from the meeting, realized that I need to step up my time commitment so you should be seeing a lot more of these journal entries.
  • I drew myself a little archetecture diagram which I think helped a lot. (I was wasting time having to re-figure thing out...) I basically understand what needs to be done now, and there's plenty to do. The two main components besides the main Quero component (and UI) are the QueryManager and the NetworkManager. The query and network managers might end up using their own sub-components but probably just classes. The coding overhead for using components is fairly steep. Keeping the main archetecture on components and just using classes for the hidden elements of each manager seems like a reasonable design.
  • Currently the design has no interfacce between the QueryManager and the NetworkManager. We'll probably need one soon rather than passing all events through the Main component. It would be nice to keep the Quero component as dumb as possible and serve mainly as an interface to the UI perhaps. I'm not entirely sure where the role boundary is between QueryManager and NetworkManager. In a traditional app the QueryManager would use a NetworkManager to pass queries on to appropriate hosts and recive queries from the network. In one.world though it seems that the QueryManagers should just pass the queries directly because the network is implemented undernieth the remote events. In this sense then the NetworkManager would only be responsible for things like discovery, network structure, and master browser elections. Not as a traditional access point for remote resources.
  • I get confused from time to time about what the component constructor should be doing and what the start method should be doing, and what the init method should be doing...
  Goals for next week:
  • Get Quero up and running and ideally two nodes discovering eachother and passing some messages.
  • Get a basic discovery service working. First at least be able to specify an IP for a node to link up with and join a simple network. Then add a naive discovery service using multicast with an incrementing TTL field.
  • Design and implement the state that the NetworkManager will need for the network structure.
  • Set up some remote event handler importing and exporting. Define the useful message types.
  • If there's any time left after all of this (and a big project for Gribble, and a Math midterm) hook up some of the UI controls to make for easier testing.
 

Week 2: ending Tuesday 02-13
 
  Last week:
  • Completed an initial working version of the FileTransferManager
  Goals for this week:
  • Switch over to the one.world team with Chia-yang
  • Set up the one.world environment at home and run through the tutorial
  Time spent:
  • 02-07: 45 min.: Talked with Robert, who gave me a brief refresher couse on the one.world architecture
  • 02-09: 1.5 hours: Downloaded, set up, and compiled one.world on my home machine.
  • 02-10: 2 hours: Read Java coding specs, a few good little tidbits, and adding javadoc comments an nice indenting to FTM. Started reading about turorial before bed so I can ponder one.world while I go to sleep. Then I'll be ready to go as soon as I wake up...
  • 02-11: 2 hours: starting the tutorial, pretty straightforward after the little session with Robert. Will finish tomorrow. Got sidetracked adding good things to FTM like thread groups for stopping transfers gracefully, etc. Need to find out if ThreadLocal is appropriate in this case. I tried to test running a few file transfers simultaneously but I probably need to use bigger files so they last longer.
  • 02-12: 1 hour: Finished going over tutorial, I'll probably need to look at it again, there's plenty there to pick up on. Also added ThreadGroups to FTM for Stop methods to locate the right Thread with.
  Comments:
  • Talking with Robert who gave a brief overview of one.world just as a refresher. A lot of the concepts are similar to COM which I'm familiar with from work. Otherwise things probably would have been confusing. (It takes time and exposure to grasp any new design methodology (aka platform)) Anyway I probably learned in half an hour about 3 hours worth of studying, and a few tricks like using Skeletor and the main shell that would have taken days of use before diging up... It's always best to have someone tell you these things
  • Read through the documentation on setting up which seemed geared towards those actually working on developing the platform so it was confusing because of the target audience. Also it was vague at times probably because the target audience is the actual developers familiar with the system. Recomend making a clearer distinction between and seperationg documentation for Windows and Linux installations.
  • One.world still seems like a big jumble of code that can probably be made to do something but I'm not sure how. We'll see if this changes after the tutorial. Usually things are easier to understand once you've tried to do something with it, rather then just read about it. A pictorial component architecture overview would be nice.
 

Week 1: ending Tuesday 02-06
 
  Goals for this week:
  • Write Java Point To Point TCP File Transfer code (aka FileTransferManager) with ui callbacks
  Time spent:
  • 01-30: 2.5 hours: Set up JDK and Forte in Linux. Started FTM
  • 02-04: 1.5 hours reading 3 coding: Finished initial FTM
  • 02-05: .5 hours reading: Brushed up on Swing for looking at the UI update callbacks. May be a bit tricky because Swing is not thread safe. I doubt that we can use the UI event handler in one.world. We'll probably need a UI
  Comments::
  • Implementing a file transfer utility is fairly simple in Java. Opening up a few different readers and writers and run them through some sockets... I decided to make each side of the connection work on it's own thread. A good idea so that the calls to send and recieve a multi-megabyte file are non-blocking. Another design decision was to read and transmit 1400 byte chunks of files. Assuming that most hosts will run on ethernet connections with 1500 byte packet limits. This may or may not matter because of the buffered streams. I'd like to test different settings if there is some time.
  • I did give a brief moments thought to security so that people aren't just setting up reciever connections on other peoples hosts and storing files on them, etc. The hostname that connects to the ServerSocket is checked against that which the calling method passed it. So a transfer must be initiated by an agreement between hosts talking on whatever main communication link is running. Real security should be implemented there.
  Goals for next week:
  • Finish and test FileTransferManager code
 


David Carothers
Last modified: Wed Mar 14 22:00:43 PST 2001