User Tools

Site Tools


developersguide:blockprotocol

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
developersguide:blockprotocol [2014/11/13 09:13]
lionelsambuc
developersguide:blockprotocol [2016/04/18 07:26] (current)
dcvmoole [Requests and replies] there's nothing blocking about requests really
Line 31: Line 31:
 ==== Requests and replies ==== ==== Requests and replies ====
  
-The block driver protocol follows ​a strict blocking ​request-reply model: a party requests service from a block driver by sending it a request message, and the block driver will respond that request with a reply message. Multiple requests may be sent at once. It is up to the driver to decide the order in which the requests are replied to. Internally, the driver may implement any form of parallelism,​ queuing, etcetera, as it sees fit. For the purpose of keeping track of its own requests, the caller supplies an (opaque) ID value in each request; the driver copies this ID into each corresponding reply.+The block driver protocol follows ​the basic request-reply model: a party requests service from a block driver by sending it a request message, and the block driver will respond that request with a reply message. Multiple requests may be sent at once. It is up to the driver to decide the order in which the requests are replied to. Internally, the driver may implement any form of parallelism,​ queuing, etcetera, as it sees fit. For the purpose of keeping track of its own requests, the caller supplies an (opaque) ID value in each request; the driver copies this ID into each corresponding reply.
  
 Since requests may be sent synchronously or asynchronously,​ the block driver must use //​driver_receive()//​ to receive a request along with the IPC primitive used to send the request. After handling the request, it should either use //send()// or //​sendnb()//​ to reply to calls made using //​sendrec()//,​ or use //​asynsend3()//​ with the <fs small>​AMF_NOREPLY</​fs>​ flag to reply to calls made using //​asynsend()//​ (so that no asynchronous reply can satisfy a synchronous //​sendrec()//​). This is taken care of by libblockdriver. Since requests may be sent synchronously or asynchronously,​ the block driver must use //​driver_receive()//​ to receive a request along with the IPC primitive used to send the request. After handling the request, it should either use //send()// or //​sendnb()//​ to reply to calls made using //​sendrec()//,​ or use //​asynsend3()//​ with the <fs small>​AMF_NOREPLY</​fs>​ flag to reply to calls made using //​asynsend()//​ (so that no asynchronous reply can satisfy a synchronous //​sendrec()//​). This is taken care of by libblockdriver.
developersguide/blockprotocol.txt · Last modified: 2016/04/18 07:26 by dcvmoole