/[webpac]/trunk2/openisis/doc/Server.txt
This is repository of my old source code which isn't updated any more. Go to git.rot13.org for current projects!
ViewVC logotype

Contents of /trunk2/openisis/doc/Server.txt

Parent Directory Parent Directory | Revision Log Revision Log


Revision 337 - (show annotations)
Thu Jun 10 19:22:40 2004 UTC (19 years, 9 months ago) by dpavlin
File MIME type: text/plain
File size: 5974 byte(s)
new trunk for webpac v2

1 operating an OpenIsis server with one or more threads
2
3
4 * server interface
5
6 From the OpenIsis API, all db IO calls can be redirected to a server.
7 However, only the basic database access is done by the server,
8 convenience functions like formatting are processed locally.
9 There would be no point in processing stream IO or record utilities remotely.
10 While database control calls are generally NOT accessible via the wire,
11 some of them have counterparts for managing the server session.
12
13
14 * the multisession server
15
16 A multisession server deploys multiple threads to process requests
17 from multiple sessions in parallel. Each session occupies at most one
18 thread at a time (and, of course, vice versa), but threads and sessions
19 are not (necessarily) bound to each other during their lifetime.
20
21
22 Rather there is a dispatcher monitoring all session's input streams
23 and allocating threads as needed.
24 However, there is one thread bound to the default session,
25 which is thus not subject to dispatching.
26
27
28 * principles of communication
29
30 The server communicates with it's clients by sending messages over streams.
31 While the server's IO multiplexer engine is designed to allow for a variety
32 of applications, the database server API's messages are OpenIsis records.
33 There are field numbers and subfield codes assigned to each
34 parameter of a request. Parameters which are records themselves
35 are encapsulated transparently, i.e. by giving their length in advance.
36
37
38 In basic communication mode (i.e. not using a wrapper protocol like HTTP),
39 these records are then transmitted as lines consisting of a field number
40 printed using ASCII decimal digits, followed by a TAB, followed
41 by the field's contents and a newline (NL).
42 Each NL within the contents is converted to NL-TAB and
43 on the receiving side, each line starting with a TAB is treated
44 as continuation of the previous field.
45 Transmission ends with an empty line.
46
47
48 * session streams
49
50 The streams connected to a session are usually backed by some kind of socket.
51 Since requests carry a session id,
52 sessions may be multiplexed onto one or more sockets,
53 possibly using one connection per request or even UDP datagrams.
54 Each response, however, is sent on the socket where the corresponding
55 request was received on and in the order request went in.
56
57
58 The default session is always bound 1:1 to a communication channel,
59 not subject to multiplexing
60 (i.e. session id 0 is implied by and allowed only on this channel).
61 Yet this channel may be a named pipe or localhost or unix socket,
62 which does not have a permanent client connection
63 and may be controlled by the multiplexer.
64
65
66 Typically, it's client side is a Tcl belonging to the same process,
67 either a tclsh as controller of a multisession server
68 or a wish as the sole client within a standalone application.
69 On Unix, this server thread is most easily connected to by
70 a pair of pipes (using Tcl_CreateFileHandler).
71 Under Windows, things are much more complicated ...
72
73 In general, the marshalling to a stream might of course
74 be skipped when using inter thread communication.
75 Either side might just prepare the record to the session's
76 request or response buffer, resp., and then ring some bell
77 like Tcl_ThreadQueueEvent and Tcl_ThreadAlert.
78
79
80 * the server's heart
81
82 A server enters multisession mode by starting up the multiplexer.
83 The multiplexer may run in a separate thread or in the same
84 one as the default session, depending on the means by which
85 the default session is connected to it's controlling input.
86 The multiplexer starts up some number of worker threads,
87 listens on a TCP port and then sits in a loop
88 - selecting the server socket and all already open connections
89 - accepting new connections
90 - writing available responses to writable sockets
91 - reading the first few bytes from readable sockets
92 (from which it not already has a partly request)
93 to check for session ids (SID).
94 If a request does not start with a SID,
95 it belongs to (i.e. optionally creates) the session bound to this socket.
96 - deciding from which (readable) sockets more should be read.
97 Input belonging to sessions already in process is left alone.
98 - reading available input, checking for complete requests
99 - if the multiplexer handles default session's input and there
100 is a request available, it is processed in this thread
101 - queing complete requests for processing
102 - checking the response queue for completed requests,
103 collecting responses and freeing threads.
104 Requests producing large amounts of output
105 (similar to piggybacked Z39.50 present requests)
106 may create partly responses before beeing finished.
107 - assigning from the request queue to available worker threads
108
109 Note that this multiplexer architecture is in no way special
110 to OpenIsis database access, but suited and intended to drive
111 a session oriented, but otherwise multi-purpose application server.
112
113 In the context of serving an OpenIsis database,
114 the server is essentially stateless.
115 It may at any time decide to drop inactive sessions,
116 unless it was talked into (configured for) promising to keep result sets.
117
118
119 * the single threaded server
120
121 The single threaded version of the server has only one thread
122 and typically only one session, i.e. the default session.
123
124 Note that single threaded means there is only one thread accessing
125 the database. There may still be other threads in the process,
126 e.g. to care for the user interface.
127
128
129 A single session server is not very useful in itself.
130 However, it allows some user interface to be programmed using
131 the server API regardless of whether a local or remote DB is accessed,
132 and to discouple even local processing from the UI.
133
134 Another variant of a single threaded server is multisession,
135 i.e. running a session multiplexer, but not dispatching jobs
136 to a worker thread pool.
137 This may be useful as minimal server on platforms with no
138 or broken multithreading support, especially Win 9x/Me
139 (which lacks the NT call SignalObjectAndWait).
140
141
142 ---
143 $Id: Server.txt,v 1.3 2003/02/14 17:30:33 kripke Exp $

  ViewVC Help
Powered by ViewVC 1.1.26