Assignment 2 of comp6231

FAQ of Assignment 2 of comp6231

> 1.In the programming problem, I have to impelment all communication among
> e-traders using the UDP/IP datagram protocol, but as I know, the IIOP used
> by ORB is built on TCP/IP, How should we switch to use UDP/IP in CORBA?

1. Using a UDP is irrelevant with whatever CORBA is implemented. You are
working completely outside CORBA architecture which means you are just
exchange some information between e-traders so that they can fulfill a
request in CORBA. So, you simply implement a socket communication by
yourself inside a "buyitem" or "sellitem".

> 2.All data operations must be performed atomically (in a both-or-none
> fashion) without
> any interference from other operations, is this because the communication
> among e-traders based on UDP/IP, which gives no gurantee to commuication?
> Does this require I have to use transcation in my application? and if that
> is true, should I use JTA?

2. This is not because of what communication mechanism you are using. Even
you are using a reliable communication channel like TCP, still you are
facing this "atomic" issue because it is the business logic. Surely you
should treat them as a remote transaction. And you are not supposed to use
JTA because you are actually implememt it by yourself.
　

> Just as the first assignment, in this assignment,I still need to run
> several server in the same host for testing. Therefore, I need to change
> the server port number. However, in the example, I didn't see
> corresponding commands. Maybe it use the default port number. Also, I
> didn't see any corresponding articles to change the server port number on
> internet( not the central orbd port number,which can be change in the
> command line.).

1. You don't have to use different port number to differenciate different
servers.
2. Different servers do not conflict with port number, at least we cannot
see it.
3. Each server register with different "server-name" or "registery-name" so
that client can talk with them by using this "registery-name". Try to run
several servers in same host with a command line parameter so that each
"binds" with a different "registery name".
　

> I got a question about the new function in assignment 2. Since e-traders
> can trader both the items bought and the items they manage, how can we
> decide the re-selling price for the items bought. 'coz the selling price
> is changing, one can buy the same item at different prices. We can sum the
> quantity for each kind of items, but I don't think we should simply take
> the average of the prices.

The purpose of adding the pricing change periodically is for fault-tolerance
project to force you to take timing factor into consideration. So, let's
stick to a simple way with common-sense. Assume you buy some item and try to
resell them, then there is no reason to treat them differently from your own
item. My suggestion is just average selling price whenever you buy in some
item with different price. And periodically changing the price as if they
are items you manage.
In one sentence, using the buying price to average your current selling
price by weight of quantity. And then changing the selling price like your
own item.
　

> Hi, in your tips, you said that we cannot change the parameters in
> sellItem function. If we transfer parameters like the teacher's
> requirement, we need more functions in interface to make sure whether the
> buyer has enough money in the account based the current seller's price,
> and we need to consider more things about the synchronization. Do you mean
> that we can define more functions in the interface and only not to change
> the function parameters that the teacher give us?
>
Obviously this is not a good idea because professor define the interface
with reasons and we should follow strictly. But how should we solve the
negative balance trouble? It is simple, just let us assume negative balance
is acceptable. Please read requirement and tell me if professor asks us to
check balance? No, he only asks to check quantity. So, we don't care about
whether balance is negative or not.

> Second question is that some student said that only the tradeItems
> function use UDP, the buyItem, sellItem and printreport function still
> need to be through central ORB, is it like that?

In fact, all functions are CORBA function or interfaces. Only in the
"tradeitem", the server between server part is done by UDP instead of CORBA
RPC because performance reason.

　

> In assignment2, the teacher said"Furthermore, for performance reasons,
> implement all communication among e-traders using the UDP/IP datagram
> protocol."
> Does it mean each server has the address of other servers?Then, when the
> client send the requirement, this server can directly communicate with
> other servers, which needn't through the central orb.
>
Yes. Only for "tradeItem" we don' t have to ask e-trader to communicate with
other e-trader by CORBA. Instead the server-server communicates with UDP.
And it is purely for performance reason.

> According to that, need we still define the sell function in the orb
> interface. The sell function is just the function used among etrader
> servers. It is more like a private function, used by buy function.
> Urgent for your write back.

Yes, you still keep the sell function as RMI. In face you can almost keep
most of your A1, but only change the RPC part of CORBA.

1. All functions "buyItem, sellItem, printReport, tradeItem" are all and only methods in IDL. Please follow strictly the NAME AND PARAMETER given by professor because this acts as a contract between you and professor. If you really want to define some "help interface" used between servers, please justify yourself with following reasons:

a) simplicity: Say, why cannot we assume negative balance while professor doesn't explicitly required for?

b) efficiency: Is more communication really worthwhile? Distributed system view efficiency as one of top priority, so we should avoid multi-rounds communication within one operation.

2. Let's keep as much A1 as possible. So, "buyItem" will still internally call other e-trader's sellItem via CORBA.

3. Instead of using "buyItem"+"sellItem", tradeItem is implemented completely differently. That is to say, the server-server communication is using UDP instead CORBA RPC so that we don't have to define extra methods in interface.

The UDP listening port number is another issue. Just like the "item name" in A1, you can hard code this or setup by configure file. By introducing CORBA, we have another choice, that is "name service" which is like a central database. So, if you are ambitious enough you can even write some "deployment" information in "name service" so that both client and server can access them. But I should warn you that it is not trivial to iterate name service and you may not have time for this.
　

And the understatement of using UDP is that the UDP listener or server must run within a thread. Otherwise you cannot listen incoming UDP requests. And the introduction of UDP not only introduce more synchronization problem, but also deadlock issues here. So, apart from solving the "remote transaction" problem, also try to tackle the "deadlock" problem.

> Hello,
> I read the FAQ but I still don't see how the sellItem() fits.
> The sellItem() is a remote method between eTraders. If we use UDP to do
> the communication between eTraders, it means that we don't use any
> remote method call anymore. If we use remote method call, the
> underlying ORB Core will prevent us from choosing transport layer.
> Could you clarify that?
> Thanks
　

1. Whatever you have done in A1 should be kept at maximum. So, if you use RMI in A1, simply change them to CORBA. The RPC in essential are all similar. The difference is just how you register your RPC and how to find the registery of them.

2.Only for "tradeItem", we want to implement it as following:

a) It is a RPC between client and one e-trader.

b) The called e-trader internally use UDP to communicate with other e-trader to settle transactions.

c) The called e-trader return reply as normal RPC in CORBA. So, essentially the server-server communication is by UDP.

... we don't have much information about the synchronizing solution and therefore we can assume some wrong ideas which will ends to lossing marks, like " Synchronizing(this) " which I tought is a good solution but later one it came wrong.

If you send us some samples or some solution like other parts, I will really appritiate that.

This is a difficult question to answer in a few words. And if you are brave enough you can browse some of my old tutorial material. But I warn you that you probably don't have time to give such a try when you are not familiar with both questions, contexts, and solutions.

Anyway here is the link and you can give a glimpse.

summer

http://users.encs.concordia.ca/~qingz_hu/comp6231_summer.html

fall:

http://users.encs.concordia.ca/~qingz_hu/soen423_fall.htm

This example demos the "fine-grained" synchronization at "item-level" which has the highest efficiency. see explanation at below.

http://users.encs.concordia.ca/~qingz_hu/assignment_1_of_soen423.htm#secondTry

1. Generally speaking, you can declare your methods to be "sycnrhonized" to make your class safe.

2. This maybe enough for most application. (The simple, inefficient application.) However, when multiple threads is involved and when deadlock issue is proposed, you cannot make all your methods "synchronized". Instead, you can "refine" your operation to divide your action into some sub functions. And only make those "refined" sub routine "synchronized" as long as they are "smallest" or "basic atomic unit action". (i.e. All your interface methods are not "synchronized" and internally call these "refined sub rountine" which are "synchronized".

To synchronize a sub routine or to sychronize a block of code are generally the same.

synchronized void subroutine()

{..}

...

synchronized(anObject)

{

...

}

The difference maybe as subtle as the small difference with issues of software engineering. ("Thread-safe" class usually suffers bad efficiency and you can "dynamically make "thread-unsafe" class to be "thread-safe" class with "synchronized (thread_unsafe_class_object)". While the "thread-safe class" loses this flexibility.)

3. The third approach is simply throw away "synchronized" which is simply a "mutex" by using more flexible synchronization tools. When you use Semaphore(1) which is a mutex, it seems no difference than "synchronized". However, Semaphore has "non-blocking" "locking methods" which can help you safely retreat from deadlock trap.

Other tools like those various "locks" in java is no more flexible than Semaphore. Thus I wouldn't be interested in looking into it.

4. However, the most thorough analysis may reveal the exact global variables which need to be synchronized and then this is another object-oriented approach. Let's "objectize" those objects and put semaphore at their level. Therefore when multiple thread try to access those objects they are simply working at object level and since the semaphore belongs to each item they will not interfere with each other. This needs lots of Semaphore, but it maybe much efficient.

http://users.encs.concordia.ca/~qingz_hu/assignment_1_of_soen423.htm#secondTry

In all this is not a simple technique which can be grasped within a couple of days. Hance it needs time to think and try.