From a0b1c101ef388f5ba89c7a5ac10557c02c4e5c6d Mon Sep 17 00:00:00 2001 From: =?utf8?q?Ji=C5=99=C3=AD=20Sitera?= Date: Fri, 6 Feb 2009 15:23:42 +0000 Subject: [PATCH] Notif socket related TODO removed. Notif pool will be integral part of the library, only edg_wll_NotifClosePool described. --- org.glite.lb.doc/examples/notif_example.c | 3 ++- org.glite.lb.doc/src/notification_api.tex | 28 +++++++++++++++++++++------- 2 files changed, 23 insertions(+), 8 deletions(-) diff --git a/org.glite.lb.doc/examples/notif_example.c b/org.glite.lb.doc/examples/notif_example.c index df2f14c..3e9bb2d 100644 --- a/org.glite.lb.doc/examples/notif_example.c +++ b/org.glite.lb.doc/examples/notif_example.c @@ -116,7 +116,8 @@ receive_err: /* Drop registration if not used anymore edg_wll_NotifDrop() */ edg_wll_NotifIdFree(recv_notif_id); - + edg_wll_NotifCloseFd(ctx); + /* edg_wll_NotifClosePool(ctx); */ register_err: diff --git a/org.glite.lb.doc/src/notification_api.tex b/org.glite.lb.doc/src/notification_api.tex index 2466ddc..5d922c3 100644 --- a/org.glite.lb.doc/src/notification_api.tex +++ b/org.glite.lb.doc/src/notification_api.tex @@ -43,10 +43,14 @@ The typical notification workflow consist of 3 tasks: soft-state registration and must be regullarly refreshed by the owner. \item Receiving the data from notification. The \LB infrastructure - provides data queuing and garantied delivery (while the registration - is valid). + provides data queuing and garanteed delivery (while the registration + is valid). \end{itemize} +The client notification library contains a code providing a pool of +receiving sockets/connections to optimize a parallel receiving of +notifications. + For complete reference of all API funcions please see the header file. The next sessions briefly describe main facts about API funcions. @@ -92,12 +96,22 @@ machine than where the registration was done, it is possible. The client must use the \verb'edg_wll_NotifBind' call to inform the notification infrastructure (interlogger) about its location change. -There is a possibility to reuse existing socket for multiple notifications (calls of -\verb'edg_wll_NotifReceive'. \TODO{Reusing of socket reasons/recomendations} +The notification API cleanup procedure should be called when +finalizing the client (\verb'edg_wll_NotifClosePool' and +\verb'edg_wll_NotifCloseFd' calls -- where the later is optional +-- see the next section). + +\subsubsection{External versus internal management of notification socket} +A notification socket used by \verb'edg_wll_NotifReceive' call to +receive the notifications is automatically created during the +\verb'edg_wll_NotifNew' or \verb'edg_wll_NotifBind' calls. -\TODO{Normal usage of edg\_wll\_NotifCloseFd? Shoul be used?} +It the user wants to use its own socket (for example to be used in +main select() call) it can be created and closed by the user and set +as a parameter (fd) to all calls mentioned above. -\TODO{Receiving notification from more sources on one socket.} +When using automatically created socket it must be closed explicitly +by calling \verb'edg_wll_CloseFd'. \subsection{Registering and receiving notification example} @@ -127,5 +141,5 @@ The \verb'edg_wll_NotifReceive' call returns one notification. If no notificatio ready for delivery, the call waits until some notification arrival or timeout: \lstinputlisting[title={\bf File: }\lstname,numbers=left,linerange=receive-end\ receive]{notif_example.c} - +# Finalizing the client -- 1.8.2.3