Illustrates implementation of WebWork message passing in terms of
-
a): current Web technologies (HTTP/CGI), and
-
b) next generation multithreaded compute-servers
|
|
This diagram illustrates point-to-point communication between Web servers, used to implement a webflow channel between compute-web modules. Two extreme implementation modes are described: a) based on today's Web server technology, and b) based on thread memory mapped high performance implementation, expected in future Web compute-servers. Subsequent steps, represented by a sequence of labelled lines in the figure, are described below in both implementation modes.
|
|
a) Today's Web server mode: (1) -- M1 locks O1 on S1 disk. (2) -- M1 sends POST HTTP message to S2 with M2 URL in the header sector and with O1 URL in the body sector. (3) -- S2 activates M2 via CGI and passes O1 URL as a command-line argument. (4) -- M2 sends GET method to S1 with O1 URL in the header. (5) -- S1 fetches O1 from its document tree. (6) -- S1 sends the content of O1 to M2 which completes the GET exchange. (7) -- M2 saves O1 by overwriting current I2 on the S2 disk. If I2 is
locked, M2 waits (blocks). (8) -- After O1 is saved on the S2 disk, M2 returns 'end-of-transfer' acknowledgment to M1 which completes the POST exchange. (9) -- M1 unlocks O1 and exists.
|
|
b) Compute-server (future Web server) mode: (1) - M1 locks its memory object O1. (2) - M1 checks if socket connection to M2 is in M1 connection table. If yes, go to (5) below. Otherwise, M1 connects to S2 and sends M2 creation script. (3) - S2 spawns M2 and acknowledges. (4) - M1 receives acknowledge message and saves new socket in connection table. (5) - M1 gets O1 handle. (6) - M1 writes O1 to M2 using socket lib calls. (7) - M2 reads O1 using socket lib calls. If I2 is free, O1 buffer is
copied directly to I2 buffer. If I2 is locked, M2 creates O1 clone and blocks. (8) - M2 sends acknowledge to M1. (9) - M1 unlocks O1 and blocks.
|
