1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
|
<!-- $Id$ -->
<HTML>
<HEAD>
<TITLE>Overview of the ACE Network Services</TITLE>
<BODY text = "#000000"
link="#000fff"
vlink="#ff0f0f"
bgcolor="#ffffff">
<HR>
<H3>Overview of the ACE Network Services</H3>
ACE provides a <A HREF=".">
standard library</A> of network services:<P>
<TABLE>
<TD>
<UL>
<LI><A HREF="#name-overview">Naming Service</A>
<LI><A HREF="#time-overview">Time Service</A>
<LI><A HREF="#token-overview">Token Service</A>
</UL>
</TD>
<TD>
<UL>
<LI><A HREF="#server-logging-overview">Server Logging Service</A>
<LI><A HREF="#client-logging-overview">Client Logging Service</A>
<LI><A HREF="#logging-strategy-overview">Logging Strategy Service</A>
</UL>
</TD>
</TABLE>
These services play two roles in ACE:<P>
<UL>
<LI> They provide reusable components for common distributed system
tasks such as logging, naming, locking, and time synchronization.<P>
<LI> They illustrate how to utilize ACE features such as the <A
HREF="http://www.cs.wustl.edu/~schmidt/ACE-papers.html#ipc">IPC
wrappers</A>, <A HREF="http://www.cs.wustl.edu/~schmidt/ACE-papers.html#reactor">Reactor</A>,
<A HREF="http://www.cs.wustl.edu/~schmidt/ACE-papers.html#config">Service Configurator</A>, <A
HREF="http://www.cs.wustl.edu/~schmidt/ACE-papers.html#initialize">Service
Initialization</A>, and <A
HREF="http://www.cs.wustl.edu/~schmidt/ACE-papers.html#concurrency">Concurrency</A>
components. <P> </UL>
The heart of the ACE network services is the <A
HREF="http://www.cs.wustl.edu/~schmidt/ACE-papers.html#config">Service
Configurator</A>, which is an object-oriented framework that automates
the configuration and reconfiguration of multi-service daemons. All
the ACE network services are configured using the Service
Configurator. Please refer to the <A HREF="../ACE-INSTALL.html">online
documentation</a> for more information on installing and testing the
ACE network services.<P>
<P><HR>
<A NAME="name-overview">
<H3> Overview of Naming Service</H3>
A Naming Service associates names with values in a distributed
system. Clients can query these values using these names as keys. Such
a name-to-value association is called a <I> Name Binding </I>. Name
bindings are defined relative to a <I> Naming Context </I>. A naming
context is a collection that contains a set of name bindings in which
each name is unique. Different names can be bound to the same value in
the same or different naming contexts at the same time. There are
three types of naming contexts: <P>
<OL>
<LI> Process Local Naming Context: Name bindings are accessible from
processes with the same name running on the same host. <P>
<LI> Node Local Naming Context: Name bindings are accessible from all
processes running on the same host. <P>
<LI> Network Local Naming Context: Name bindings are accessible from
all processes running on any machine within a (sub)network. <P>
</OL>
<P>
To bind a name is to create a name binding in a given context.
Querying a value using a name determines the value associated with the
name in a given context. Note that a name is always bound relative to
a context. Thus, there are no absolute names. <P>
The following are the key classes in the ACE Naming Service: <P>
<UL>
<LI> <B><TT> Class Naming_Context </TT></B> <P>
This is the main class ``entry point'' into the Naming Service. It is
used both by client processes and by server process. It manages access
to the appropriate Name/Binding database (that is the file where
Name/Bindings are stored) and it also manages the communication
between a client process and the server (by using class Name_Proxy,
which is a private member of Naming_Context). If a client process
runs on the same host as the server no IPC is necessary because the
Naming_Context uses shared memory. <P>
<LI> <B><TT> Class Name_Acceptor </TT></B> <P>
The Name_Acceptor allocates in its handle_input() routine a new
instance of class Name_Handler on the heap, and accepts connections
into this Name_Handler. <P>
<LI> <B><TT> Class Name_Handler </TT></B> <P>
The class Name_Handler represents the server side of communication
between client and server. It interprets incoming requests to the
Net_Local namespace and delegates the requests to its own
Naming_Context (which is the Net_Local namespace on the current
host). For communication it uses the helper classes Name_Request and
Name_Reply.<P>
<LI> <B> Dependencies </B> <P>
The ACE Naming Service uses ACE_WString String classes since it must
handle wide character strings in order to support
internationalization. <P>
</UL>
The following describes how to configure the Name_Server server and
client test applications. <P>
<UL>
<LI> <B> Startup configuration </B> <P>
Configuring a Name_Server server or client requires specifying all or
some of the following parameters. These parameters can be passed in to
main through command line as follows:<P>
<TABLE cellpadding = 10 cellspacing = 0 border = 5>
<TD VALIGN = TOP ALIGN = LEFT>
<B> Option </B>
</TD>
<TD VALIGN = TOP ALIGN = LEFT>
<B> Description </B>
</TD>
<TD VALIGN = TOP ALIGN = LEFT>
<B> Default value </B>
</TD>
<TR>
<TD VALIGN = TOP ALIGN = LEFT>
-c <naming context> <BR>
</TD>
<TD VALIGN = TOP ALIGN = LEFT>
Naming Context to use. Can be either "PROC_LOCAL" or "NODE_LOCAL" or
"NET_LOCAL" <BR>
</TD>
<TD VALIGN = TOP ALIGN = LEFT>
PROC_LOCAL
</TD>
<TR>
<TD VALIGN = TOP ALIGN = LEFT>
-h <hostname>
</TD>
<TD VALIGN = TOP ALIGN = LEFT>
Specify the server hostname (needed by Name Server clients for
PROC_LOCAL naming context)
</TD>
<TD VALIGN = TOP ALIGN = LEFT>
ACE_DEFAULT_SERVER_HOST
</TD>
<TR>
<TD VALIGN = TOP ALIGN = LEFT>
-p <nameserver port> <BR>
</TD>
<TD VALIGN = TOP ALIGN = LEFT>
Port number where the server process expects requests <BR>
</TD>
<TD VALIGN = TOP ALIGN = LEFT>
ACE_DEFAULT_SERVER_PORT
</TD>
<TR>
<TD VALIGN = TOP ALIGN = LEFT>
-l <namespace dir> <BR>
</TD>
<TD VALIGN = TOP ALIGN = LEFT>
Directory that holds the NameBinding databases <BR>
</TD>
<TD VALIGN = TOP ALIGN = LEFT>
ACE_DEFAULT_NAMESPACE_DIR
</TD>
<TR>
<TD VALIGN = TOP ALIGN = LEFT>
-P <process name> <BR>
</TD>
<TD VALIGN = TOP ALIGN = LEFT>
Name of the client process
</TD>
<TD VALIGN = TOP ALIGN = LEFT>
argv[0]
</TD>
<TR>
<TD VALIGN = TOP ALIGN = LEFT>
-s <database name> <BR>
</TD>
<TD VALIGN = TOP ALIGN = LEFT>
Name of the database. NameBindings for the appropriate naming context
are stored in file <namespace_dir>/<database name>.
</TD>
<TD VALIGN = TOP ALIGN = LEFT>
<I> null </I>
</TD>
<TR>
<TD VALIGN = TOP ALIGN = LEFT>
-d <debug>
</TD>
<TD VALIGN = TOP ALIGN = LEFT>
Turn debugging on/off
</TD>
<TD VALIGN = TOP ALIGN = LEFT>
0 (off)
</TD>
<TR>
<TD VALIGN = TOP ALIGN = LEFT>
-T <trace>
</TD>
<TD VALIGN = TOP ALIGN = LEFT>
Turn tracing on/off
</TD>
<TD VALIGN = TOP ALIGN = LEFT>
0 (off)
</TD>
<TR>
<TD VALIGN = TOP ALIGN = LEFT>
-v <verbose>
</TD>
<TD VALIGN = TOP ALIGN = LEFT>
Turn verbose on/off
</TD>
<TD VALIGN = TOP ALIGN = LEFT>
0 (off)
</TD>
</TABLE>
<P>
<LI><B>Examples</B><P>
<OL>
<LI> Here is what a config file would look like for starting up a
server at port 20222 using NET_LOCAL naming context with database
called MYDATABSE located in directory /tmp:
<PRE> <CODE>
dynamic Naming_Service Service_Object *
../lib/netsvcs:_make_ACE_Name_Acceptor()
"-p 20222 -c NET_LOCAL -l /tmp -s MYDATABASE"
</PRE> </CODE>
<LI> Here is what a config file would look like for starting up a
client that connects to a Name Server running on host
tango.cs.wustl.edu at port 20222:
<PRE> <CODE>
dynamic Naming_Service_Client Service_Object *
../lib/netsvcs:_make_Client_Test()
"-h tango.cs.wustl.edu -p 20222"
</PRE> </CODE>
</OL>
Note:<P>
<UL>
<LI> Values for parameters can also be passed in using environment
variables. For example, instead of specifying absolute hostname or
port numbers in the config file, we can use $HOST and $PORT,
respectively, in the file (assuming that these environment variables
have been set). <P>
<LI> If the environment variable LD_LIBRARY_PATH (in the case of UNIX)
or PATH (in the case of Win32) contains the path to the shared object
files or dll, then the config file can be further simplified. Instead
of specifying a path to the shared object or dll, only the name of the
shared object or dll would suffice. That is, the Service Configurator
makes use of LD_LIBRARY_PATH (on UNIX) or PATH (on Win32) to look for
the shared object files or dlls.
</UL>
</UL>
<P><HR><P>
<A NAME="time-overview">
<H3> Overview of Time Service</H3>
Time Service provides accurate, fault-tolerant clock synchronization
for computers collaborating in local area networks and wide area
networks. Synchronized time services are important in distributed
systems that require multiple hosts to maintain accurate global
time. The architecture of the distributed time service contains the
following Time Server, Clerk, and Client components: <P>
<UL>
<LI> <I> Time Server </I> answers queries about the time made by
Clerks. <P>
<LI> <I> Clerk </I> queries one or more Time Servers to determine
the correct time, calculates the approximate correct time using one of
several distributed time algorithms and updates its own local system
time. <P>
<LI> <I> Client </I> uses the global time information maintained by
a Clerk to provide consistency with the notion of time used by clients
on other hosts. <P>
</UL>
<P>
The following are the key classes in the ACE Time Service: <P>
<UL>
<LI> <B><TT> Class TS_Server_Handler </TT></B> <P>
TS_Server_Handler represents the server side of communication between
clerk and server. It interprets incoming requests for time updates,
gets the system time, creates a reply in response to the request and
then sends the reply to the clerk from which it received the request.
For communication it uses the helper class Time_Request.<P>
<LI> <B><TT> Class TS_Server_Acceptor </TT></B> <P>
TS_Server_Acceptor allocates in its handle_input routine a new instance
of class TS_Server_Handler on the heap, and accepts connections into this
TS_Server_Handler.<P>
<LI> <B><TT> Class TS_Clerk_Handler </TT></B> <P>
TS_Clerk_Handler represents the clerk side of communication between
clerk and server. It generates requests for time updates every timeout
period and then sends these requests to all the servers it is
connected to asynchronously. It receives the replies to these requests
from the servers through its handle_input method and then adjusts the
time using the roundtrip estimate. It caches this time, which is
subsequently retrieved by TS_Clerk_Processor.<P>
<LI> <B><TT> Class TS_Clerk_Processor </TT></B> <P>
TS_Clerk_Processor creates a new instance of TS_Clerk_Handler for
every server connection it needs to create. It periodically calls
send_request() of every TS_Clerk_Handler to send a request for time
update to all the servers. In the process, it retrieves the latest
time cached by each TS_Clerk_Handler and then uses it to compute its
notion of the local system time.<P>
<LI> <B> Algorithms </B> <P>
Currently, updating the system time involves taking the average of all
the times received from the servers.<P>
</UL>
The following is a description of how to configure the Time Server
clerk and server services: <P>
<UL>
<LI> <B> Startup configuration </B> <P>
Configuring a server requires specifying the port number of the
server. This can be specified as a command line argument as follows: <P>
-p <port number>
<P>
A clerk communicates with one or more server processes. To communicate
with the server process, a client needs to know the INET_Addr, where
the server offers its service. The configuration parameters namely the
server port and server host are passed as command line arguments when
starting up the clerk service as follows: <P>
-h <server host1>:<server port1> -h <server host2>:<server port2> ...
<P>
Note that multiple servers can be specified in this manner for the
clerk to connect to when it starts up. The server name and the port
number need to be concatenated and separated by a ":". In addition,
the timeout value can also be specified as a command line argument as
follows:
<P>
-t timeout
<P>
The timeout value specifies the time interval at which the clerk
should query the servers for time updates.
<P>
By default a Clerk does a non-blocking connect to a server. This can
be overridden and a Clerk can be made to do a blocking connect by
using the -b flag.
<P>
<LI> <B>Examples</B> <P>
<OL>
<LI> Here is what a config file would look like for starting up a
server at port 20202:
<PRE> <CODE>
dynamic Time_Service Service_Object *
../lib/netsvcs:_make_ACE_TS_Server_Acceptor()
"-p 20202"
</PRE> </CODE>
<LI> Here is what a config file would look like for starting up a
clerk that needs to connect to two servers, one at tango and one at
lambada:
<PRE> <CODE>
dynamic Time_Server_test Service_Object *
../lib/netsvcs:_make_ACE_TS_Clerk_Connector ()
"-h tango:20202 -h lambada:20202 -t 4"
</PRE> </CODE>
</OL>
Note:<P>
<UL>
<LI> These files would vary if the services are run on NT. For
example, instead of using *.so, we would have to use *.dll.<P>
<LI> Values for parameters can also be passed in using environment
variables. For example, instead of specifying absolute hostname or
port numbers in the config file, we can use $HOST and $PORT,
respectively, in the file (assuming that these environment variables
have been set). <P>
<LI> If the environment variable LD_LIBRARY_PATH (in the case of UNIX)
or PATH (in the case of Win32) contains the path to the shared object
files or dll, then the config file can be further simplified. Instead
of specifying a path to the shared object or dll, only the
name of the shared object or dll would suffice. That is, the Service
Configurator makes use of LD_LIBRARY_PATH (on UNIX) or PATH (on Win32)
to look for the shared object files or dlls.
</UL>
<P>
</UL>
<P><HR><P>
<H3><A NAME="token-overview">Token Service</A></H3>
The ACE Token Service provides local and remote mutexes and
readers/writer locks. For information regarding the deadlock
detection algorithm, check out ACE_Token_Manager.h. For information
about an implementation of the Composite Pattern for Tokens, check out
Token_Collection.h. The classes which implement the local and remote
synchronization primitives are listed below:<P>
<UL>
<LI> <B><TT>ACE_Local_Mutex</TT></B><P>
This class is a more general-purpose synchronization mechanism
than SunOS 5.x mutexes. For example, it implements "recursive
mutex" semantics, where a thread that owns the token can
reacquire it without deadlocking. In addition, threads that
are blocked awaiting the token are serviced in strict FIFO
order as other threads release the token (SunOS 5.x mutexes
don't strictly enforce an acquisition order). Lastly,
ACE_Local_Mutex performs deadlock detection on acquire
calls.<p>
<LI> <B><TT>ACE_Remote_Mutex</TT></B><P>
This is the remote equivalent to ACE_Local_Mutex. The
Remote_Mutex class offers methods for acquiring, renewing, and
releasing a distributed synchronization mutex. Similar to
ACE_Local_Mutex, ACE_Remote_Token_Proxy offers recursive
acquisition, FIFO waiter ordering, and deadlock detection. It
depends on the Token Server for its distributed synchronization
semantics.<p>
<LI> <B><TT>ACE_Local_RLock</TT></B><P>
This class implements the reader interface to canonical
readers/writer locks. Multiple readers can hold the lock
simultaneously when no writers have the lock. Alternatively,
when a writer holds the lock, no other participants (readers or
writers) may hold the lock. This class is a more
general-purpose synchronization mechanism than SunOS 5.x
RLocks. For example, it implements "recursive RLock"
semantics, where a thread that owns the token can reacquire it
without deadlocking. In addition, threads that are blocked
awaiting the token are serviced in strict FIFO order as other
threads release the token (SunOS 5.x RLockes don't strictly
enforce an acquisition order).<P>
<LI> <B><TT>ACE_Local_WLock</TT></B><P>
This class implements the writer interface to canonical
readers/writer locks. Multiple readers can hold the lock
simultaneously when no writers have the lock. Alternatively,
when a writer holds the lock, no other participants (readers or
writers) may hold the lock. This class is a more
general-purpose synchronization mechanism than SunOS 5.x WLock.
For example, it implements "recursive WLock" semantics, where a
thread that owns the token can reacquire it without
deadlocking. In addition, threads that are blocked awaiting
the token are serviced in strict FIFO order as other threads
release the token (SunOS 5.x WLocks don't strictly enforce an
acquisition order).<P>
<LI> <B><TT>ACE_Remote_RLock</TT></B><P>
This is the remote equivalent to ACE_Local_RLock. Multiple
readers can hold the lock simultaneously when no writers have
the lock. Alternatively, when a writer holds the lock, no
other participants (readers or writers) may hold the lock.
ACE_Remote_RLock depends on the ACE Token Server for its
distributed synchronization semantics.<P>
<LI> <B><TT>ACE_Remote_RLock</TT></B><P>
This is the remote equivalent to ACE_Local_WLock.<P>
</UL>
The Token Server provides distributed mutex and readers/writer lock
semantics to the ACE Token library. ACE_Remote_Mutex,
ACE_Remote_RLock, and ACE_Remote_WLock, are proxies to the Token
Server. The following are the key classes in the ACE Token
Server:<P>
<UL>
<LI> <B><TT>class Token_Acceptor</TT></B><P>
The Token_Acceptor is a Token_Handler factory. It accepts
connections and passes the service responsibilities off to a
new Token_Handler.<p>
<LI> <B><TT>class Token_Handler</TT></B><P>
This class is the main class ``entry point'' of the ACE Token service. It
receives token operation requests from remote clients and turns
them into calls on local tokens (acquire, release, renew, and
remove). In OMG CORBA terminology, it is an ``Object Adapter.'' It also
schedules and handles timeouts that are used to support "timed
waits." Clients used timed waits to bound the amount of time
they block trying to get a token.<P>
</UL>
The following describes how to configure the Token Server:<P>
<UL>
<LI> <b>Startup configuration</B><P>
The only parameter that the Token Server takes is a listen port
number. You can specify a port number by passing a "-p
<port_number>" to the application. This can be done via the
svc.conf file.<P>
<LI> <B>Examples </B><P>
Here is an example svc.conf entry that dynamically loads the
Token Server specifying port number to listen on for client
connections:<P>
<code><pre>
dynamic Token_Service Service_Object *
../lib/netsvcs:_make_ACE_Token_Acceptor()
"-p 10202"
</code></pre>
<P>
</UL>
Note:<P>
<UL>
<LI> These files would vary if the services are run on NT. For
example, instead of using *.so, we would have to use *.dll.<P>
<LI> Values for parameters can also be passed in using environment
variables. For example, instead of specifying absolute hostname or
port numbers in the config file, we can use $HOST and $PORT,
respectively, in the file (assuming that these environment variables
have been set). <P>
<LI> If the environment variable LD_LIBRARY_PATH (in the case of UNIX)
or PATH (in the case of Win32) contains the path to the shared object
files or dll, then the config file can be further simplified. Instead
of specifying a path to the shared object or dll, only the
name of the shared object or dll would suffice. That is, the Service
Configurator makes use of LD_LIBRARY_PATH (on UNIX) or PATH (on Win32)
to look for the shared object files or dlls.
</UL>
<P><HR><P>
<A NAME="server-logging-overview">
<H3>Overview of Server Logging Service</H3>
The Server Logging Service provides a concurrent, multi-service daemon
that processes logging records received from one or more client hosts
simultaneously. The object-oriented design of the Server Logging
Service is decomposed into several modular components that perform
well-defined tasks. <P>
The following are the key classes in the Server Logging Service: <P>
<UL>
<LI> <B> <TT> Server_Logging_Handler </TT> </B> <P>
The Server_Logging_Handler class is a parameterized type that is
responsible for processing logging records sent to the Server from
participating client hosts. When logging records arrive from the
client host associated with a particular Logging Handler object, the
handle_input() method of the Server_Logging_Handler class is called
which in turn formats and displays the records on one or more output
devices (such as the printer, persistent storage, and/or console
devices. <P>
<LI> <B> <TT> Server_Logging_Acceptor </TT> </B> <P>
The class Server_Logging_Acceptor allocates in its handle_input()
routine a new instance of class Server_Logging_Handler on the heap,
and accepts connections into this Server_Logging_Handler. <P>
</UL>
The following describes how to configure the Logging Server:<P>
<UL>
<LI> <b>Startup configuration</B><P>
The only parameter that the Logging Server takes is a listen
port number. You can specify a port number by passing a "-p
<port_number>" to the application. This can be done via the
svc.conf file.<P>
<LI> <B>Examples </B><P>
Here is an example svc.conf entry that dynamically loads the
Logging Server specifying port number to listen on for client
connections:<P>
<PRE> <CODE>
dynamic Server_Logging_Service Service_Object *
../lib/netsvcs:_make_ACE_Server_Logging_Acceptor()
"-p 10202"
</PRE></CODE>
<P>
</UL>
Note:<P>
<UL>
<LI> These files would vary if the services are run on NT. For
example, instead of using *.so, we would have to use *.dll.<P>
<LI> Values for parameters can also be passed in using environment
variables. For example, instead of specifying absolute hostname or
port numbers in the config file, we can use $HOST and $PORT,
respectively, in the file (assuming that these environment variables
have been set). <P>
<LI> If the environment variable LD_LIBRARY_PATH (in the case of UNIX)
or PATH (in the case of Win32) contains the path to the shared object
files or dll, then the config file can be further simplified. Instead
of specifying a path to the shared object or dll, only the
name of the shared object or dll would suffice. That is, the Service
Configurator makes use of LD_LIBRARY_PATH (on UNIX) or PATH (on Win32)
to look for the shared object files or dlls.
</UL>
<P><HR><P>
<A NAME="client-logging-overview">
<H3>Overview of Client Logging Service</H3>
The Client Logging Service multiplexes messages recevied from
different applications to the Server Logging Daemon running on a
designated host in a network/internetwork.
The following are the key classes in the Client Logging Service: <P>
<UL>
<LI> <B> <TT> Client_Logging_Handler </TT> </B> <P>
The Client_Logging_Handler class is a parameterized type that is
responsible for setting up a named pipe and using it to communicate
with different user processes on the same host. Once logging records
arrive from these processes, the handler reads these records in
priority order, performs network-byte order conversions on
multiple-header fields, and then transmits these records to the Server
Logging daemon across the network. <P>
<LI> <B> <TT> Client_Logging_Connector </TT> </B> <P>
The class Client_Logging_Connector connects to the Server Logging
daemon and then in its handle_input() routine it allocates a new
instance of the Client_Logging_Handler on the heap. <P>
</UL>
The following describes how to configure the Logging Client:<P>
<UL>
<LI> <b>Startup configuration</B><P>
Configuring a Logging Client requires specifying all or some of the
following parameters. These parameters can be passed in to main
through command line as follows:<P>
<TABLE cellpadding = 10 cellspacing = 0 border = 5>
<TD VALIGN = TOP ALIGN = LEFT>
<B> Option </B>
</TD>
<TD VALIGN = TOP ALIGN = LEFT>
<B> Description </B>
</TD>
<TD VALIGN = TOP ALIGN = LEFT>
<B> Default value </B>
</TD>
<TR>
<TD VALIGN = TOP ALIGN = LEFT>
-h <hostname> <BR>
</TD>
<TD VALIGN = TOP ALIGN = LEFT>
Hostname of the Server Logging Daemon <BR>
</TD>
<TD VALIGN = TOP ALIGN = LEFT>
ACE_DEFAULT_SERVER_HOST
</TD>
<TR>
<TD VALIGN = TOP ALIGN = LEFT>
-p <port number>
</TD>
<TD VALIGN = TOP ALIGN = LEFT>
Port number of the Server Logging Daemon <BR>
</TD>
<TD VALIGN = TOP ALIGN = LEFT>
ACE_DEFAULT_LOGGING_SERVER_PORT
</TD>
<TR>
<TD VALIGN = TOP ALIGN = LEFT>
-p <rendezvous key>
</TD>
<TD VALIGN = TOP ALIGN = LEFT>
Rendezvous key used to create named pipe
</TD>
<TD VALIGN = TOP ALIGN = LEFT>
ACE_DEFAULT_RENDEZVOUS
</TD>
</TABLE>
<P>
<LI> <B>Examples </B><P>
Here is an example svc.conf entry that dynamically loads the
Logging Client specifying host name and port number of the
Logging Server: <P>
<PRE> <CODE>
dynamic Client_Logging_Service Service_Object *
../lib/netsvcs:_make_ACE_Client_Logging_Connector()
"-h tango.cs.wustl.edu -p 10202"
</PRE></CODE>
<P>
</UL>
Note:<P>
<UL>
<LI> These files would vary if the services are run on NT. For
example, instead of using *.so, we would have to use *.dll.<P>
<LI> Values for parameters can also be passed in using environment
variables. For example, instead of specifying absolute hostname or
port numbers in the config file, we can use $HOST and $PORT,
respectively, in the file (assuming that these environment variables
have been set). <P>
<LI> If the environment variable LD_LIBRARY_PATH (in the case of UNIX)
or PATH (in the case of Win32) contains the path to the shared object
files or dll, then the config file can be further simplified. Instead
of specifying a path to the shared object or dll, only the
name of the shared object or dll would suffice. That is, the Service
Configurator makes use of LD_LIBRARY_PATH (on UNIX) or PATH (on Win32)
to look for the shared object files or dlls.
</UL>
<P><HR><P>
<A NAME="logging-strategy-overview">
<H3> Overview of Logging Strategy Service</H3>
The Logging Strategy Service can be used to control the output of all the
network services. It can be invoked with certain flags that determine
where the output of all the services should go. The Logging Strategy
Service sets the flags in ACE_Log_Msg, which controls all the streams
through macros such as ACE_DEBUG, ACE_ERROR, and ACE_ERROR_RETURN. If
default behavior is required, the Logging Strategy Service need not be
invoked or it can be invoked with no parameters. <P>
The following describes how to configure the Logging Strategy
Service:<p>
<UL>
<LI> <b>Startup configuration</B><P>
Here are the command line arguments that can be given to the Logging
Strategy Service: <P>
-f <flag1>|<flag2>|<flag3> (etc...) <P>
where a flag can be any of the following: <P>
<TABLE cellpadding = 10 cellspacing = 0 border = 5>
<TD VALIGN = TOP ALIGN = LEFT>
<B> Flags </B>
</TD>
<TD VALIGN = TOP ALIGN = LEFT>
<B> Description </B>
</TD>
<TR>
<TD VALIGN = TOP ALIGN = LEFT>
STDERR <BR>
</TD>
<TD VALIGN = TOP ALIGN = LEFT>
Write messages to stderr. <BR>
</TD>
<TR>
<TD VALIGN = TOP ALIGN = LEFT>
LOGGER <BR>
</TD>
<TD VALIGN = TOP ALIGN = LEFT>
Write messages to the local client logger deamon. <BR>
</TD>
<TR>
<TD VALIGN = TOP ALIGN = LEFT>
OSTREAM <BR>
</TD>
<TD VALIGN = TOP ALIGN = LEFT>
Write messages to the ostream that gets created by specifying a
filename (see below) <BR>
</TD>
<TR>
<TD VALIGN = TOP ALIGN = LEFT>
VERBOSE <BR>
</TD>
<TD VALIGN = TOP ALIGN = LEFT>
Display messages in a verbose manner <BR>
</TD>
<TR>
<TD VALIGN = TOP ALIGN = LEFT>
SILENT <BR>
</TD>
<TD VALIGN = TOP ALIGN = LEFT>
Do not print messages at all <BR>
</TD>
</TABLE>
<P>
Note: If more than one flag is specified, the flags need to be 'OR'ed
as above syntax shows. Make sure there is no space in between the flag
and '|'. <P>
-s filename
<P>
If the OSTREAM flag is set, this can be used to specify the filename
where the output should be directed. Note that if the OSTREAM flag is
set and no filename is specified, ACE_DEFAULT_LOGFILE will be used to
write the output to. <P>
<LI> <B> Examples: </B> <P>
Here is an example svc.conf entry that dynamically loads the
Logging Strategy Service specifying that the output be sent
to STDERR: <P>
<PRE> <CODE>
dynamic Logging_Strategy_Service Service_Object *
../lib/netsvcs:_make_ACE_Logging_Strategy()
"-f STDERR"
</PRE></CODE>
<P>
<OL>
<LI> To direct output only to STDERR, specify command line arguments as: <P>
"-f STDERR"
<P>
<LI> To direct output to both STDERR and a file called "mylog", specify
command line arguments as: <P>
"-f STDERR|OSTREAM -s mylog"
</OL>
Note:<P>
<UL>
<LI> These files would vary if the services are run on NT. For
example, instead of using *.so, we would have to use *.dll.<P>
<LI> Values for parameters can also be passed in using environment
variables. For example, instead of specifying absolute hostname or
port numbers in the config file, we can use $HOST and $PORT,
respectively, in the file (assuming that these environment variables
have been set). <P>
<LI> If the environment variable LD_LIBRARY_PATH (in the case of UNIX)
or PATH (in the case of Win32) contains the path to the shared object
files or dll, then the config file can be further simplified. Instead
of specifying a path to the shared object or dll, only the
name of the shared object or dll would suffice. That is, the Service
Configurator makes use of LD_LIBRARY_PATH (on UNIX) or PATH (on Win32)
to look for the shared object files or dlls.
</UL>
</UL>
<P><HR><P>
Back to the <A HREF="http://www.cs.wustl.edu/~schmidt/ACE.html">
ACE</A> home page.
<!--#include virtual="/~schmidt/cgi-sig.html" -->
</BODY>
</HTML>
|
