Welcome to soen423 tutorial! My name is: qingzhe huang My email is: qingz_hu@cse....

General requirement: 1. Do the assignment by yourself and I may look into your source code. 2. Submit your work electronically under proper category. i.e. theory assignment #, programming assignment # etc. 3. Submit a "design-choice-report" document along with your source code and it is worth as much as source code. In the report, you are supposed to explain your design choices on perspective "correctness", "efficiency" etc. For example, there are a lot of "synchronization-traps" and how you solve them. And those synchronization tools generally will slow your system and how you design to speed up the system.etc.  4. I may give some comments on marking your assignment. So, please take a look at them because I don't like people to repeat same mistakes again and again.

Assignment 1 Mistakes in A1 Assignment 2 　 　 　 The tutorial: Wed 17:45-18:45 Thu 17:00-18:00 H-929 On Thursday session, I will give some tutorials.

Soen423 Blog: 09/24/2006 Set up website for soen423 and add general tips and comments on assignment 1. 09/27/2006 Add a detailed analysis of programming assignment in second try. 09/28/2006 The "Hello World" example should be as simple as possible. So, download this "RMI-hello world" example and learn RMI from scratch. Also there are some FAQ's in my last tutorial even though many issues are not applicable. So, just pay attention to no.18. In case you are first time to use java like me before, here is a simple hint about the most surprising things in java from a C++ programmer. 09/30/2006 Maybe this sample program can convince you how important "thread-safe" is in distributed system. And most frequently it is up to developer to make sure your application code to be correctly synchronized. 01/10/2006 Here comes a comment about A1. From now on, I will add those questions which I answered in my email here about A1. 03/10/2006 I think I might be misleading some of you guys. However, no matter how you interpret the "startAuction", you have to guarantee the unique item no you return for each request. This is the bottom line. 04/10/2006 Here comes a simple example of UDP socket in java. And here comes the first try of assignment 2. 05/10/2006 How to test the assignment 1? I give a small suggestion during tutorial. And to be fair with all of class here it is the scheme. In the client program, we create a number of threads and all of them try to call "placeBid" for the same item no. with a random "proposedBid". Of course within the "timeToClose", only the highest bid will be placed at the end. So, by checking the "currentBid" after testing with the highest random number we generated, at least we can see if anything is going wrong. If your "placeBid" is not properly synchronized, there is a big chance that your final bid is not the highest bid. Another thing about "ArrayList" which is not "thread-safe" class. You can convince yourself by reading the comment in source code. Usually when you install "jdk", you have the source code downloaded. So, unzip to find "java\util\ArrayList.java". At the top of those comments from programmer, you will see it is not synchronized. So, be careful to use this kind of class unless you put the "get" and "put" methods of "ArrayList" inside your critical_section part. 11/10/2006 Here goes some mistakes and issues I noticed during marking. And also please go to your "web mail" to download my comment on your A1 because I don't want to see repeated mistakes in A2. 15/10/2006 I should say I am also learning by acting as a TA. 25/10/2006 UDP is not a reliable communication socket and this topic is only for advanced students who already finished with both synchronization and deadlock issue only! If your server socket is busying with “dualbid” and a new incoming message will be lost. Does your client socket re-send a request? How do you implement the “exactly-once-semantics” here? Do you need a “transaction-ID” in your request packet and acknowledge packet? A simple demo program shows you the lost packet in UDP communication. 　 22/11/2006 I am a bit busy with my “wesnoth” and here comes the demo sheet. Also I write some tips and questions about project in the demo sheet. The group leader should download it and mail back to me at qingz_hu@cse.concordia.ca 24/11/2006 During tutorial, I discussed with one group about their project design. I want to point out here that the “dualBid” must be treated like a “remote-transaction” which means “either all or none”. So, when one server crashes, I think you need to freeze all other running servers to wait for the crashed server to wake up. Otherwise you cannot maintain the semantics of transaction. Here I give an example. Suppose one client wants to place a pair of antique vases in the auction and it is well known “set items” that nobody would buy only one of the pair. That is reason why the seller places two items at the same time in a “dualBid” call. So, in my opinion, you cannot treat the two items as independent items in “dualBid”. 01/12/2006 Yesterday I happened to move and some unpredictable event prevented me from coming to lab. I was unable to notice you guys and I apologize for this. I will try to make it up on an extra lab on Monday 17:00pm-18:00pm on Dec. 4. Or if you have any urgent question we can set up an appointment by email. Thank you. 05/12/2006 During demo today, one group discussed with me the definition of "primary-backup replication". My point is that the "backup-server" should not be repeat the same request relayed by "primary-server". During discussion I cannot persuade the group. Now I am bit clear about this issue. You see, if backup server is identical as primary server then a dual-bid in primary will be repeated in backup server. The remote host will receive two identical dual-bid operation which is not acceptable. Maybe this is part of reason they don't complete the "dual-bid" part of this project because as long as the operation is limited on local server you can repeat with no problem. However, if the operation is between two servers then your repeat operation will be problem and this is the most significant feature of distributed system. Another interesting part I want to remind you guys that in your lecture you probably learned the "replication" model in which you have a "leader" among all replica. And you think it over you will see this leader usually does the operation of "remote-transaction" and then broadcast the result to all other replica. This is also the part of reason we need to look into various kinds of "broadcasts". Good luck of your final.