Logo AND Algorithmique Numérique Distribuée

Public GIT Repository
Remove extern declaration for gras_opt_trp_nomoredata_on_close.
[simgrid.git] / src / gras / Transport / README
1 There is a plugin mechanism in here, and the selection is automatic
2
3 If you open a socket in SG realm, you'll get a SG socket.
4 If you open a socket in RL realm, you'll get a TCP socket.
5
6 To get a file socket, you'll have to build it manually using
7 gras_socket_client_from_file() to read from it, or
8 gras_socket_server_from_file() to write to it.
9
10 There is no way (yet?) to build a pipe socket, so threads have to
11 discuss using network sockets, or xbt_queue_t structures.
12
13 IMPLEMENTATION NOTES ABOUT THE SG SIDE
14
15 This area is quite messy. The thing is that I strived too much to keep
16 the existing interface, which is loosely inspired from BSD sockets.
17
18 Vocabulary: 
19   Server is the one who created the master socket. 
20   Client is the one connecting to that from a remote host. 
21   Their roles keep the same for the whole connection duration. 
22   Sender and Receiver denote the roles during one message exchange.
23   If the server answers to the client, it becomes the sender while the
24   client becomes the receiver. 
25   All this seems trivial, but confusion is easy and dangerous.
26
27
28 The connection story goes that way. When we create a master socket, we
29 look whether the given port is free on that host or not. For that, we
30 traverse the gras_hostdata_t->ports dynar, which contains
31 gras_sg_portrec_t records. If it's free, we create a socket with a
32 gras_trp_sg_sock_data_t structure. Here is that struct:
33
34 typedef struct { 
35   smx_process_t server; 
36   smx_process_t client;
37     
38   smx_rdv_t rdv_server; /* The rendez-vous point to use */
39   smx_rdv_t rdv_client; /* The rendez-vous point to use */
40   smx_action_t comm_recv; /* The comm of irecv on receiver side */
41 } s_gras_trp_sg_sock_data_t,*gras_trp_sg_sock_data_t;
42
43 In GRAS, there is a listener process, in charge of pumping everything
44 coming from the network and post that to the main user thread. That
45 to overlap (incoming) communications and computations.
46 In SG, this is done by ensuring that a receive is posted on every
47 opened socket, and having the listener doing a smx_sem_waitany() to
48 find the first ending one (in RL, a select+ddt_recv does the same).
49
50 Another extra complexity is due to the fact that when the user
51 receives a message, it gets a socket being a mean to contact the
52 sender of that message. In RL, that's easy since sockets are
53 full-duplex. In SG, I have to either create a new socket for each
54 message (slow and leak-prone), or maintain a set of opened sockets on
55 receiver side and check if the one I need is there or create it. The
56 approach used currently is to give to the receiver a pointer to the
57 structure created on the sender side directly.
58
59 At the end of the day, everything is as if there were master socket
60 and working sockets, just like in BSD. There is no explicit accept.
61 Master sockets get created by gras_socket_server() and friends. You
62 can recognize them by the fact that the rdv_client field is always
63 NULL. Such sockets are not really used to exchange data, but more to
64 establish connections. For actual exchanges, you need a working socket
65 created by gras_socket_client() and friends. So, they are created on
66 client side, but the master side will see it as message expeditor when
67 getting a message.
68
69 You can see which side of the socket you are with the
70 gras_socket_im_the_server() function, which is designed for that.