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 lousely inspirated 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 connexion 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 connexion 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 comming from the network and post that to the main user thread. That
  45 to overlap (incomming) 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 connexions. 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.