![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to 4.t CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSDReno / share / doc / ps1 / 08.ipc|
Return to 4.t CVS log | Up to [CSRG BSD Unix] / 43BSDReno / share / doc / ps1 / 08.ipc |
1.1 ! root 1: .\" Copyright (c) 1986 The Regents of the University of California. ! 2: .\" All rights reserved. ! 3: .\" ! 4: .\" Redistribution and use in source and binary forms are permitted ! 5: .\" provided that the above copyright notice and this paragraph are ! 6: .\" duplicated in all such forms and that any documentation, ! 7: .\" advertising materials, and other materials related to such ! 8: .\" distribution and use acknowledge that the software was developed ! 9: .\" by the University of California, Berkeley. The name of the ! 10: .\" University may not be used to endorse or promote products derived ! 11: .\" from this software without specific prior written permission. ! 12: .\" THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR ! 13: .\" IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED ! 14: .\" WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. ! 15: .\" ! 16: .\" @(#)4.t 1.4 (Berkeley) 3/7/89 ! 17: .\" ! 18: .\".ds RH "Client/Server Model ! 19: .bp ! 20: .nr H1 4 ! 21: .nr H2 0 ! 22: .sp 8i ! 23: .bp ! 24: .LG ! 25: .B ! 26: .ce ! 27: 4. CLIENT/SERVER MODEL ! 28: .sp 2 ! 29: .R ! 30: .NL ! 31: .PP ! 32: The most commonly used paradigm in constructing distributed applications ! 33: is the client/server model. In this scheme client applications request ! 34: services from a server process. This implies an asymmetry in establishing ! 35: communication between the client and server which has been examined ! 36: in section 2. In this section we will look more closely at the interactions ! 37: between client and server, and consider some of the problems in developing ! 38: client and server applications. ! 39: .PP ! 40: The client and server require a well known set of conventions before ! 41: service may be rendered (and accepted). This set of conventions ! 42: comprises a protocol which must be implemented at both ends of a ! 43: connection. Depending on the situation, the protocol may be symmetric ! 44: or asymmetric. In a symmetric protocol, either side may play the ! 45: master or slave roles. In an asymmetric protocol, one side is ! 46: immutably recognized as the master, with the other as the slave. ! 47: An example of a symmetric protocol is the TELNET protocol used in ! 48: the Internet for remote terminal emulation. An example ! 49: of an asymmetric protocol is the Internet file transfer protocol, ! 50: FTP. No matter whether the specific protocol used in obtaining ! 51: a service is symmetric or asymmetric, when accessing a service there ! 52: is a \*(lqclient process\*(rq and a \*(lqserver process\*(rq. We ! 53: will first consider the properties of server processes, then ! 54: client processes. ! 55: .PP ! 56: A server process normally listens at a well known address for ! 57: service requests. That is, the server process remains dormant ! 58: until a connection is requested by a client's connection ! 59: to the server's address. At such a time ! 60: the server process ``wakes up'' and services the client, ! 61: performing whatever appropriate actions the client requests of it. ! 62: .PP ! 63: Alternative schemes which use a service server ! 64: may be used to eliminate a flock of server processes clogging the ! 65: system while remaining dormant most of the time. For Internet ! 66: servers in 4.3BSD, ! 67: this scheme has been implemented via \fIinetd\fP, the so called ! 68: ``internet super-server.'' \fIInetd\fP listens at a variety ! 69: of ports, determined at start-up by reading a configuration file. ! 70: When a connection is requested to a port on which \fIinetd\fP is ! 71: listening, \fIinetd\fP executes the appropriate server program to handle the ! 72: client. With this method, clients are unaware that an ! 73: intermediary such as \fIinetd\fP has played any part in the ! 74: connection. \fIInetd\fP will be described in more detail in ! 75: section 5. ! 76: .PP ! 77: A similar alternative scheme is used by most Xerox services. In general, ! 78: the Courier dispatch process (if used) accepts connections from ! 79: processes requesting services of some sort or another. The client ! 80: processes request a particular <program number, version number, procedure ! 81: number> triple. If the dispatcher knows of such a program, it is ! 82: started to handle the request; if not, an error is reported to the ! 83: client. In this way, only one port is required to service a large ! 84: variety of different requests. Again, the Courier facilities are ! 85: not available without the use and installation of the Courier ! 86: compiler. The information presented in this section applies only ! 87: to NS clients and services that do not use Courier. ! 88: .NH 2 ! 89: Servers ! 90: .PP ! 91: In 4.3BSD most servers are accessed at well known Internet addresses ! 92: or UNIX domain names. For ! 93: example, the remote login server's main loop is of the form shown ! 94: in Figure 2. ! 95: .KF ! 96: .if t .ta .5i 1.0i 1.5i 2.0i 2.5i 3.0i 3.5i ! 97: .if n .ta .7i 1.4i 2.1i 2.8i 3.5i 4.2i 4.9i ! 98: .sp 0.5i ! 99: .DS ! 100: main(argc, argv) ! 101: int argc; ! 102: char *argv[]; ! 103: { ! 104: int f; ! 105: struct sockaddr_in from; ! 106: struct servent *sp; ! 107: ! 108: sp = getservbyname("login", "tcp"); ! 109: if (sp == NULL) { ! 110: fprintf(stderr, "rlogind: tcp/login: unknown service\en"); ! 111: exit(1); ! 112: } ! 113: ... ! 114: #ifndef DEBUG ! 115: /* Disassociate server from controlling terminal */ ! 116: ... ! 117: #endif ! 118: ! 119: sin.sin_port = sp->s_port; /* Restricted port -- see section 5 */ ! 120: ... ! 121: f = socket(AF_INET, SOCK_STREAM, 0); ! 122: ... ! 123: if (bind(f, (struct sockaddr *) &sin, sizeof (sin)) < 0) { ! 124: ... ! 125: } ! 126: ... ! 127: listen(f, 5); ! 128: for (;;) { ! 129: int g, len = sizeof (from); ! 130: ! 131: g = accept(f, (struct sockaddr *) &from, &len); ! 132: if (g < 0) { ! 133: if (errno != EINTR) ! 134: syslog(LOG_ERR, "rlogind: accept: %m"); ! 135: continue; ! 136: } ! 137: if (fork() == 0) { ! 138: close(f); ! 139: doit(g, &from); ! 140: } ! 141: close(g); ! 142: } ! 143: } ! 144: .DE ! 145: .ce ! 146: Figure 2. Remote login server. ! 147: .sp 0.5i ! 148: .KE ! 149: .PP ! 150: The first step taken by the server is look up its service ! 151: definition: ! 152: .sp 1 ! 153: .nf ! 154: .in +5 ! 155: .if t .ta .5i 1.0i 1.5i 2.0i ! 156: .if n .ta .7i 1.4i 2.1i 2.8i ! 157: sp = getservbyname("login", "tcp"); ! 158: if (sp == NULL) { ! 159: fprintf(stderr, "rlogind: tcp/login: unknown service\en"); ! 160: exit(1); ! 161: } ! 162: .sp 1 ! 163: .in -5 ! 164: .fi ! 165: The result of the \fIgetservbyname\fP call ! 166: is used in later portions of the code to ! 167: define the Internet port at which it listens for service ! 168: requests (indicated by a connection). ! 169: .KS ! 170: .PP ! 171: Step two is to disassociate the server from the controlling ! 172: terminal of its invoker: ! 173: .DS ! 174: for (i = 0; i < 3; ++i) ! 175: close(i); ! 176: ! 177: open("/", O_RDONLY); ! 178: dup2(0, 1); ! 179: dup2(0, 2); ! 180: ! 181: i = open("/dev/tty", O_RDWR); ! 182: if (i >= 0) { ! 183: ioctl(i, TIOCNOTTY, 0); ! 184: close(i); ! 185: } ! 186: .DE ! 187: .KE ! 188: This step is important as the server will ! 189: likely not want to receive signals delivered to the process ! 190: group of the controlling terminal. Note, however, that ! 191: once a server has disassociated itself it can no longer ! 192: send reports of errors to a terminal, and must log errors ! 193: via \fIsyslog\fP. ! 194: .PP ! 195: Once a server has established a pristine environment, it ! 196: creates a socket and begins accepting service requests. ! 197: The \fIbind\fP call is required to insure the server listens ! 198: at its expected location. It should be noted that the ! 199: remote login server listens at a restricted port number, and must ! 200: therefore be run ! 201: with a user-id of root. ! 202: This concept of a ``restricted port number'' is 4BSD ! 203: specific, and is covered in section 5. ! 204: .PP ! 205: The main body of the loop is fairly simple: ! 206: .DS ! 207: .if t .ta .5i 1.0i 1.5i 2.0i ! 208: .if n .ta .7i 1.4i 2.1i 2.8i ! 209: for (;;) { ! 210: int g, len = sizeof (from); ! 211: ! 212: g = accept(f, (struct sockaddr *)&from, &len); ! 213: if (g < 0) { ! 214: if (errno != EINTR) ! 215: syslog(LOG_ERR, "rlogind: accept: %m"); ! 216: continue; ! 217: } ! 218: if (fork() == 0) { /* Child */ ! 219: close(f); ! 220: doit(g, &from); ! 221: } ! 222: close(g); /* Parent */ ! 223: } ! 224: .DE ! 225: An \fIaccept\fP call blocks the server until ! 226: a client requests service. This call could return a ! 227: failure status if the call is interrupted by a signal ! 228: such as SIGCHLD (to be discussed in section 5). Therefore, ! 229: the return value from \fIaccept\fP is checked to insure ! 230: a connection has actually been established, and ! 231: an error report is logged via \fIsyslog\fP if an error ! 232: has occurred. ! 233: .PP ! 234: With a connection ! 235: in hand, the server then forks a child process and invokes ! 236: the main body of the remote login protocol processing. Note ! 237: how the socket used by the parent for queuing connection ! 238: requests is closed in the child, while the socket created as ! 239: a result of the \fIaccept\fP is closed in the parent. The ! 240: address of the client is also handed the \fIdoit\fP routine ! 241: because it requires it in authenticating clients. ! 242: .NH 2 ! 243: Clients ! 244: .PP ! 245: The client side of the remote login service was shown ! 246: earlier in Figure 1. ! 247: One can see the separate, asymmetric roles of the client ! 248: and server clearly in the code. The server is a passive entity, ! 249: listening for client connections, while the client process is ! 250: an active entity, initiating a connection when invoked. ! 251: .PP ! 252: Let us consider more closely the steps taken ! 253: by the client remote login process. As in the server process, ! 254: the first step is to locate the service definition for a remote ! 255: login: ! 256: .DS ! 257: sp = getservbyname("login", "tcp"); ! 258: if (sp == NULL) { ! 259: fprintf(stderr, "rlogin: tcp/login: unknown service\en"); ! 260: exit(1); ! 261: } ! 262: .DE ! 263: Next the destination host is looked up with a ! 264: \fIgethostbyname\fP call: ! 265: .DS ! 266: hp = gethostbyname(argv[1]); ! 267: if (hp == NULL) { ! 268: fprintf(stderr, "rlogin: %s: unknown host\en", argv[1]); ! 269: exit(2); ! 270: } ! 271: .DE ! 272: With this accomplished, all that is required is to establish a ! 273: connection to the server at the requested host and start up the ! 274: remote login protocol. The address buffer is cleared, then filled ! 275: in with the Internet address of the foreign host and the port ! 276: number at which the login process resides on the foreign host: ! 277: .DS ! 278: bzero((char *)&server, sizeof (server)); ! 279: bcopy(hp->h_addr, (char *) &server.sin_addr, hp->h_length); ! 280: server.sin_family = hp->h_addrtype; ! 281: server.sin_port = sp->s_port; ! 282: .DE ! 283: A socket is created, and a connection initiated. Note ! 284: that \fIconnect\fP implicitly performs a \fIbind\fP ! 285: call, since \fIs\fP is unbound. ! 286: .DS ! 287: s = socket(hp->h_addrtype, SOCK_STREAM, 0); ! 288: if (s < 0) { ! 289: perror("rlogin: socket"); ! 290: exit(3); ! 291: } ! 292: ... ! 293: if (connect(s, (struct sockaddr *) &server, sizeof (server)) < 0) { ! 294: perror("rlogin: connect"); ! 295: exit(4); ! 296: } ! 297: .DE ! 298: The details of the remote login protocol will not be considered here. ! 299: .NH 2 ! 300: Connectionless servers ! 301: .PP ! 302: While connection-based services are the norm, some services ! 303: are based on the use of datagram sockets. One, in particular, ! 304: is the \*(lqrwho\*(rq service which provides users with status ! 305: information for hosts connected to a local area ! 306: network. This service, while predicated on the ability to ! 307: \fIbroadcast\fP information to all hosts connected to a particular ! 308: network, is of interest as an example usage of datagram sockets. ! 309: .PP ! 310: A user on any machine running the rwho server may find out ! 311: the current status of a machine with the \fIruptime\fP(1) program. ! 312: The output generated is illustrated in Figure 3. ! 313: .KF ! 314: .DS B ! 315: .TS ! 316: l r l l l l l. ! 317: arpa up 9:45, 5 users, load 1.15, 1.39, 1.31 ! 318: cad up 2+12:04, 8 users, load 4.67, 5.13, 4.59 ! 319: calder up 10:10, 0 users, load 0.27, 0.15, 0.14 ! 320: dali up 2+06:28, 9 users, load 1.04, 1.20, 1.65 ! 321: degas up 25+09:48, 0 users, load 1.49, 1.43, 1.41 ! 322: ear up 5+00:05, 0 users, load 1.51, 1.54, 1.56 ! 323: ernie down 0:24 ! 324: esvax down 17:04 ! 325: ingres down 0:26 ! 326: kim up 3+09:16, 8 users, load 2.03, 2.46, 3.11 ! 327: matisse up 3+06:18, 0 users, load 0.03, 0.03, 0.05 ! 328: medea up 3+09:39, 2 users, load 0.35, 0.37, 0.50 ! 329: merlin down 19+15:37 ! 330: miro up 1+07:20, 7 users, load 4.59, 3.28, 2.12 ! 331: monet up 1+00:43, 2 users, load 0.22, 0.09, 0.07 ! 332: oz down 16:09 ! 333: statvax up 2+15:57, 3 users, load 1.52, 1.81, 1.86 ! 334: ucbvax up 9:34, 2 users, load 6.08, 5.16, 3.28 ! 335: .TE ! 336: .DE ! 337: .ce ! 338: Figure 3. ruptime output. ! 339: .sp ! 340: .KE ! 341: .PP ! 342: Status information for each host is periodically broadcast ! 343: by rwho server processes on each machine. The same server ! 344: process also receives the status information and uses it ! 345: to update a database. This database is then interpreted ! 346: to generate the status information for each host. Servers ! 347: operate autonomously, coupled only by the local network and ! 348: its broadcast capabilities. ! 349: .PP ! 350: Note that the use of broadcast for such a task is fairly inefficient, ! 351: as all hosts must process each message, whether or not using an rwho server. ! 352: Unless such a service is sufficiently universal and is frequently used, ! 353: the expense of periodic broadcasts outweighs the simplicity. ! 354: .PP ! 355: The rwho server, in a simplified form, is pictured in Figure ! 356: 4. There are two separate tasks performed by the server. The ! 357: first task is to act as a receiver of status information broadcast ! 358: by other hosts on the network. This job is carried out in the ! 359: main loop of the program. Packets received at the rwho port ! 360: are interrogated to insure they've been sent by another rwho ! 361: server process, then are time stamped with their arrival time ! 362: and used to update a file indicating the status of the host. ! 363: When a host has not been heard from for an extended period of ! 364: time, the database interpretation routines assume the host is ! 365: down and indicate such on the status reports. This algorithm ! 366: is prone to error as a server may be down while a host is actually ! 367: up, but serves our current needs. ! 368: .KF ! 369: .DS ! 370: .if t .ta .5i 1.0i 1.5i 2.0i ! 371: .if n .ta .7i 1.4i 2.1i 2.8i ! 372: main() ! 373: { ! 374: ... ! 375: sp = getservbyname("who", "udp"); ! 376: net = getnetbyname("localnet"); ! 377: sin.sin_addr = inet_makeaddr(INADDR_ANY, net); ! 378: sin.sin_port = sp->s_port; ! 379: ... ! 380: s = socket(AF_INET, SOCK_DGRAM, 0); ! 381: ... ! 382: on = 1; ! 383: if (setsockopt(s, SOL_SOCKET, SO_BROADCAST, &on, sizeof(on)) < 0) { ! 384: syslog(LOG_ERR, "setsockopt SO_BROADCAST: %m"); ! 385: exit(1); ! 386: } ! 387: bind(s, (struct sockaddr *) &sin, sizeof (sin)); ! 388: ... ! 389: signal(SIGALRM, onalrm); ! 390: onalrm(); ! 391: for (;;) { ! 392: struct whod wd; ! 393: int cc, whod, len = sizeof (from); ! 394: ! 395: cc = recvfrom(s, (char *)&wd, sizeof (struct whod), 0, ! 396: (struct sockaddr *)&from, &len); ! 397: if (cc <= 0) { ! 398: if (cc < 0 && errno != EINTR) ! 399: syslog(LOG_ERR, "rwhod: recv: %m"); ! 400: continue; ! 401: } ! 402: if (from.sin_port != sp->s_port) { ! 403: syslog(LOG_ERR, "rwhod: %d: bad from port", ! 404: ntohs(from.sin_port)); ! 405: continue; ! 406: } ! 407: ... ! 408: if (!verify(wd.wd_hostname)) { ! 409: syslog(LOG_ERR, "rwhod: malformed host name from %x", ! 410: ntohl(from.sin_addr.s_addr)); ! 411: continue; ! 412: } ! 413: (void) sprintf(path, "%s/whod.%s", RWHODIR, wd.wd_hostname); ! 414: whod = open(path, O_WRONLY | O_CREAT | O_TRUNC, 0666); ! 415: ... ! 416: (void) time(&wd.wd_recvtime); ! 417: (void) write(whod, (char *)&wd, cc); ! 418: (void) close(whod); ! 419: } ! 420: } ! 421: .DE ! 422: .ce ! 423: Figure 4. rwho server. ! 424: .sp ! 425: .KE ! 426: .PP ! 427: The second task performed by the server is to supply information ! 428: regarding the status of its host. This involves periodically ! 429: acquiring system status information, packaging it up in a message ! 430: and broadcasting it on the local network for other rwho servers ! 431: to hear. The supply function is triggered by a timer and ! 432: runs off a signal. Locating the system status ! 433: information is somewhat involved, but uninteresting. Deciding ! 434: where to transmit the resultant packet ! 435: is somewhat problematical, however. ! 436: .PP ! 437: Status information must be broadcast on the local network. ! 438: For networks which do not support the notion of broadcast another ! 439: scheme must be used to simulate or ! 440: replace broadcasting. One possibility is to enumerate the ! 441: known neighbors (based on the status messages received ! 442: from other rwho servers). This, unfortunately, ! 443: requires some bootstrapping information, ! 444: for a server will have no idea what machines are its ! 445: neighbors until it receives status messages from them. ! 446: Therefore, if all machines on a net are freshly booted, ! 447: no machine will have any ! 448: known neighbors and thus never receive, or send, any status information. ! 449: This is the identical problem faced by the routing table management ! 450: process in propagating routing status information. The standard ! 451: solution, unsatisfactory as it may be, is to inform one or more servers ! 452: of known neighbors and request that they always communicate with ! 453: these neighbors. If each server has at least one neighbor supplied ! 454: to it, status information may then propagate through ! 455: a neighbor to hosts which ! 456: are not (possibly) directly neighbors. If the server is able to ! 457: support networks which provide a broadcast capability, as well as ! 458: those which do not, then networks with an ! 459: arbitrary topology may share status information*. ! 460: .FS ! 461: * One must, however, be concerned about \*(lqloops\*(rq. ! 462: That is, if a host is connected to multiple networks, it ! 463: will receive status information from itself. This can lead ! 464: to an endless, wasteful, exchange of information. ! 465: .FE ! 466: .PP ! 467: It is important that software operating in a distributed ! 468: environment not have any site-dependent information compiled into it. ! 469: This would require a separate copy of the server at each host and ! 470: make maintenance a severe headache. 4.3BSD attempts to isolate ! 471: host-specific information from applications by providing system ! 472: calls which return the necessary information*. ! 473: .FS ! 474: * An example of such a system call is the \fIgethostname\fP(2) ! 475: call which returns the host's \*(lqofficial\*(rq name. ! 476: .FE ! 477: A mechanism exists, in the form of an \fIioctl\fP call, ! 478: for finding the collection ! 479: of networks to which a host is directly connected. ! 480: Further, a local network broadcasting mechanism ! 481: has been implemented at the socket level. ! 482: Combining these two features allows a process ! 483: to broadcast on any directly connected local ! 484: network which supports the notion of broadcasting ! 485: in a site independent manner. This allows 4.3BSD ! 486: to solve the problem of deciding how to propagate ! 487: status information in the case of \fIrwho\fP, or ! 488: more generally in broadcasting: ! 489: Such status information is broadcast to connected ! 490: networks at the socket level, where the connected networks ! 491: have been obtained via the appropriate \fIioctl\fP ! 492: calls. ! 493: The specifics of ! 494: such broadcastings are complex, however, and will ! 495: be covered in section 5.
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.