IMPLEMENTATION NOTES ABOUT THE SG SIDE
This area is quite messy. The thing is that I strived too much to keep
-the existing interface, which is lousely inspirated from BSD sockets.
+the existing interface, which is loosely inspired from BSD sockets.
Vocabulary:
Server is the one who created the master socket.
Client is the one connecting to that from a remote host.
- Their roles keep the same for the whole connexion duration.
+ Their roles keep the same for the whole connection duration.
Sender and Receiver denote the roles during one message exchange.
If the server answers to the client, it becomes the sender while the
client becomes the receiver.
All this seems trivial, but confusion is easy and dangerous.
-The connexion story goes that way. When we create a master socket, we
+The connection story goes that way. When we create a master socket, we
look whether the given port is free on that host or not. For that, we
traverse the gras_hostdata_t->ports dynar, which contains
gras_sg_portrec_t records. If it's free, we create a socket with a
smx_rdv_t rdv_server; /* The rendez-vous point to use */
smx_rdv_t rdv_client; /* The rendez-vous point to use */
- smx_comm_t comm_recv; /* The comm of irecv on receiver side */
+ smx_action_t comm_recv; /* The comm of irecv on receiver side */
} s_gras_trp_sg_sock_data_t,*gras_trp_sg_sock_data_t;
In GRAS, there is a listener process, in charge of pumping everything
-comming from the network and post that to the main user thread. That
-to overlap (incomming) communications and computations.
+coming from the network and post that to the main user thread. That
+to overlap (incoming) communications and computations.
In SG, this is done by ensuring that a receive is posted on every
opened socket, and having the listener doing a smx_sem_waitany() to
find the first ending one (in RL, a select+ddt_recv does the same).
Master sockets get created by gras_socket_server() and friends. You
can recognize them by the fact that the rdv_client field is always
NULL. Such sockets are not really used to exchange data, but more to
-establish connexions. For actual exchanges, you need a working socket
+establish connections. For actual exchanges, you need a working socket
created by gras_socket_client() and friends. So, they are created on
client side, but the master side will see it as message expeditor when
getting a message.
-When sending, you can see if the current process is the server by
-checking if data_sock->server == SMX_process_self(). If wrong, that
-means that we are the client process today.
-
-When receiving this won't work because SMX_process_self() is the
-listener associated to the user thread. So, when receiving, you can
-see if you are on the server side or by checking if rdv_client==NULL.
-If not that means that we are on the client side today.
-
-That's messy, and should probably be reworked a bit, but I feel like
-the main issue is the interface used. It's too close and too differnt
-from BSD at the same time. One day, I hope to find the time to redo
-everything with an interface similar to the one of the 0MQ project for
-example.
\ No newline at end of file
+You can see which side of the socket you are with the
+gras_socket_im_the_server() function, which is designed for that.
