注册 登录  
 加关注
查看详情
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

zorksylar

Nothing is impossible , if distributed.

 
 
 

日志

 
 

【6.033】【notes】LEC3 : Client / Server  

2012-08-10 19:56:09|  分类: Distributed |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
Client / Server Organization
     Soft modularity && Enforced modularity
     A standard way to create modularity in a large program is to divide it up into named procedures that call one another.But it may has some risks of error can propagate from caller to callee and vice versa, and not just through their specified interfaces. for example , they may share the same address space and use the same stack, a stackoverflow problem may render the error from caller to callee.  For this reason, we identify this kind of modularity as soft modularity. soft modularity may cause propagation of errors.
    What we desire in systems is enforced modularity : modularity that is enforced by some external mechanism. This external mechanism limits the interaction among modules to the ones we desire.
     PC(procedure call) : procedure commucate via a stack in memory -- > soft modularity
     RPC(remote PC) : communicate via messages transmited by network -> enforced modularity

     Client / Service organization
     One good way to enforce modularity is to limit the interactions among modules to explicit messages. It is convenient to impose some structure on this organization by identifying participants in a communication as clients or services.
     The disadvange of C/S organization is that it requires one computer per module, which may be costly in equipment. It may also have a performace cost  because it may spend some time on send message between computers. C/S organization can also be implemented on a single computer using an OS. To archive high avaliablity or handle big workloads, a designer may choose to implement a service using multiple computers.
     C/S enforces modularity :
     1) protect memory content
     2) separates resources (heap allocator, CPU, disk, &c)
3) no fate sharing (crashes and wedges don't propagate)
4) forces a narrow spec (just msg content)

     Compared to modularity using procedure calls , C/S organization have the  advantages : the client and service don't rely on shared state(such as stack, or address space)  other than the messages. --> reduce the potential interactions , help to avoid the propagation of error.
     Some systems avoid response messages for performance reasons . For example, the X Windows System sends a series of requests that ask the service to draw something on a screen and that individuallly have no need for a response.
     Other usse of C/S :
     allow many computers share the same data.
     allow remote acess.
     allows trusted third party: EBay provides controlled sharing of auction state

     Multiple clients and services 
     C/S model is much more flexible. One service can work for multiple clients. One client can use several services ....

Remote procedure call(RPC)
     RPC intruduce a new failure mode, the "no response " failure.
     Lose request, lose reply ? --> just retry  --> may have side effects , example : trasaction in bank.
     How to handle failures for side-effecting RPCs ? --> "at most once " RPC mechanism
     At Most Once Rpc Mechansim :
     1) client gives a unique ID to each call
     2) client keeps re-sending (repeat the same ID)
     3) server rembers request Ids in a table
     4) server returns "already done" if request Id already in the table
           this is what enforces "at most once"
           can remember return value and re-return it
     5) sever may lose table (if it crashes) so it may also say "unknow"
           client / server must then re-sync Ids
    
     Client-visible outcomes of at-most-once RPC: 
           success( 1 time)
           no response (1 time)
           "already done" (1 time)
           "known" (0 or 1 time)
    
     Dealing with RPC failures , RMI  client code may has try/catch module for timeout or no reply.



  评论这张
 
阅读(364)| 评论(0)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2018