Clients on a client/server network share their resources directly with each other.

Internet, Overview

Raymond Greenlaw, Ellen M. Hepp, in Encyclopedia of Information Systems, 2003

III.E. Client/Server Model

The client/server model provides many of the network benefits described in this section. A client makes a request to the server and the server responds by satisfying the client's request. In the client/server model new clients and servers can be added incrementally as more users come on-line and the demand for services increases. That is to say, the client/server model is easily extensible and therefore scales well. Many clients can share the resources provided by a single server. This eliminates the need for each client to have their own “copy” of the resources. Each Internet service has its own associated set of clients and servers. For example, in the Web domain browsers are clients and Web servers are the servers.

Read full chapter

URL: https://www.sciencedirect.com/science/article/pii/B0122272404000964

Principles of Parallel and Distributed Computing

Rajkumar Buyya, ... S. Thamarai Selvi, in Mastering Cloud Computing, 2013

2.4.3.3 System architectural styles

System architectural styles cover the physical organization of components and processes over a distributed infrastructure. They provide a set of reference models for the deployment of such systems and help engineers not only have a common vocabulary in describing the physical layout of systems but also quickly identify the major advantages and drawbacks of a given deployment and whether it is applicable for a specific class of applications. In this section, we introduce two fundamental reference styles: client/server and peer-to-peer.

Client/server

This architecture is very popular in distributed computing and is suitable for a wide variety of applications. As depicted in Figure 2.12, the client/server model features two major components: a server and a client. These two components interact with each other through a network connection using a given protocol. The communication is unidirectional: The client issues a request to the server, and after processing the request the server returns a response. There could be multiple client components issuing requests to a server that is passively waiting for them. Hence, the important operations in the client-server paradigm are request, accept (client side), and listen and response (server side).

Clients on a client/server network share their resources directly with each other.

Figure 2.12. Client/server architectural styles.

The client/server model is suitable in many-to-one scenarios, where the information and the services of interest can be centralized and accessed through a single access point: the server. In general, multiple clients are interested in such services and the server must be appropriately designed to efficiently serve requests coming from different clients. This consideration has implications on both client design and server design. For the client design, we identify two major models:

Thin-client model. In this model, the load of data processing and transformation is put on the server side, and the client has a light implementation that is mostly concerned with retrieving and returning the data it is being asked for, with no considerable further processing.

Fat-client model. In this model, the client component is also responsible for processing and transforming the data before returning it to the user, whereas the server features a relatively light implementation that is mostly concerned with the management of access to the data.

The three major components in the client-server model: presentation, application logic, and data storage. In the thin-client model, the client embodies only the presentation component, while the server absorbs the other two. In the fat-client model, the client encapsulates presentation and most of the application logic, and the server is principally responsible for the data storage and maintenance.

Presentation, application logic, and data maintenance can be seen as conceptual layers, which are more appropriately called tiers. The mapping between the conceptual layers and their physical implementation in modules and components allows differentiating among several types of architectures, which go under the name of multitiered architectures. Two major classes exist:

Two-tier architecture. This architecture partitions the systems into two tiers, which are located one in the client component and the other on the server. The client is responsible for the presentation tier by providing a user interface; the server concentrates the application logic and the data store into a single tier. The server component is generally deployed on a powerful machine that is capable of processing user requests, accessing data, and executing the application logic to provide a client with a response. This architecture is suitable for systems of limited size and suffers from scalability issues. In particular, as the number of users increases the performance of the server might dramatically decrease. Another limitation is caused by the dimension of the data to maintain, manage, and access, which might be prohibitive for a single computation node or too large for serving the clients with satisfactory performance.

Three-tier architecture/N-tier architecture. The three-tier architecture separates the presentation of data, the application logic, and the data storage into three tiers. This architecture is generalized into an N-tier model in case it is necessary to further divide the stages composing the application logic and storage tiers. This model is generally more scalable than the two-tier one because it is possible to distribute the tiers into several computing nodes, thus isolating the performance bottlenecks. At the same time, these systems are also more complex to understand and manage. A classic example of three-tier architecture is constituted by a medium-size Web application that relies on a relational database management system for storing its data. In this scenario, the client component is represented by a Web browser that embodies the presentation tier, whereas the application server encapsulates the business logic tier, and a database server machine (possibly replicated for high availability) maintains the data storage. Application servers that rely on third-party (or external) services to satisfy client requests are examples of N-tiered architectures.

The client/server architecture has been the dominant reference model for designing and deploying distributed systems, and several applications to this model can be found. The most relevant is perhaps the Web in its original conception. Nowadays, the client/server model is an important building block of more complex systems, which implement some of their features by identifying a server and a client process interacting through the network. This model is generally suitable in the case of a many-to-one scenario, where the interaction is unidirectional and started by the clients and suffers from scalability issues, and therefore it is not appropriate in very large systems.

Peer-to-peer

The peer-to-peer model, depicted in Figure 2.13, introduces a symmetric architecture in which all the components, called peers, play the same role and incorporate both client and server capabilities of the client/server model. More precisely, each peer acts as a server when it processes requests from other peers and as a client when it issues requests to other peers. With respect to the client/server model that partitions the responsibilities of the IPC between server and clients, the peer-to-peer model attributes the same responsibilities to each component. Therefore, this model is quite suitable for highly decentralized architecture, which can scale better along the dimension of the number of peers. The disadvantage of this approach is that the management of the implementation of algorithms is more complex than in the client/server model.

Clients on a client/server network share their resources directly with each other.

Figure 2.13. Peer-to-peer architectural style.

The most relevant example of peer-to-peer systems [87] is constituted by file-sharing applications such as Gnutella, BitTorrent, and Kazaa. Despite the differences among these networks in coordinating nodes and sharing information on the files and their locations, all of them provide a user client that is at the same time a server providing files to other peers and a client downloading files from other peers. To address an incredibly large number of peers, different architectures have been designed that divert slightly from the peer-to-peer model. For example, in Kazaa not all the peers have the same role, and some of them are used to group the accessibility information of a group of peers. Another interesting example of peer-to-peer architecture is represented by the Skype network.

The system architectural styles presented in this section constitute a reference model that is further enhanced or diversified according to the specific needs of the application to be designed and implemented. For example, the client/server architecture, which originally included only two types of components, has been further extended and enriched by developing multitier architectures as the complexity of systems increased. Currently, this model is still the predominant reference architecture for distributed systems and applications. The server and client abstraction can be used in some cases to model the macro scale or the micro scale of the systems. For peer-to-peer systems, pure implementations are very hard to find and, as discussed for the case of Kazaa, evolutions of the model, which introduced some kind of hierarchy among the nodes, are common.

Read full chapter

URL: https://www.sciencedirect.com/science/article/pii/B9780124114548000024

The Internet and the Web

Stuart Ferguson, Rodney Hebels, in Computers for Librarians (Third Edition), 2003

Client/server model

The term client/server model may sound a bit daunting for those unfamiliar with computer concepts, but the concept itself is straightforward. For a user to access the Internet resources outlined earlier, there generally needs to be cooperation between two computer systems: the client and the server. The client is the user's local system, which will typically comprise a personal computer, computer peripherals (for example, a computer screen on which to display the data exchanged) and software. These components allow the user to communicate with the client and the client to communicate with the server. Note that if this book mentions ‘clients’ it is referring to such systems, and not to users (for which ‘clients’ is sometimes synonymous in librarianship literature). The server, which is a ‘remote’ system (it may be on another continent or in the next building), stores the data that the user wishes to access, retrieves data requested by the user and transmits them to the client. (The server is sometimes referred to as a host, especially in the case of the commercial servers discussed in the next chapter.)

Clients on a client/server network share their resources directly with each other.

Figure 1.3. The client/server model

The operation of the client/server model, therefore, involves the use of two sets of computer software: client software, such as the software that helps the user communicate with the computer system (see, for instance, the web browser discussed later in this chapter), and server software, such as the retrieval software (consider, for example, search engines, also discussed later). The server is generally a more powerful computer system than the client and would be expected to deal with more than one client simultaneously. One of the main advantages of the client/server model is the fact that, provided the clients and servers can understand the data passing between them, it doesn't matter what kind of computer system is used for the client. An IBM-compatible server (a computer designed according to the same standards as those of the IBM company) may be accessed, for example, by clients that are not IBM-compatible, such as Apple Macintosh computers. This depends on networking standards, one of the main topics of Chapter 7.

Read full chapter

URL: https://www.sciencedirect.com/science/article/pii/B9781876938604500070

VoIP Security

Xinyuan Wang, Ruishan Zhang, in Advances in Computers, 2011

2.2.1 SIP Messages

Based on client-server model, SIP uses request and response messages to establish sessions between two or more endpoints. To establish, manage or tear down a VoIP session, UAC will send to SIP server or UAS a SIP request message identified by one of the 13 SIP method names. The most commonly used SIP methods are the following:

REGISTER is used by the UAC to inform its current location to the SIP server.

INVITE is used by the UAC to initiate a call session.

ACK acknowledges the successful receipt of some SIP messages.

BYE terminates an established session.

CANCEL quits from the ongoing setup of a session.

OPTIONS queries the capability of a server.

Upon receiving SIP request message, the SIP server or UAS will, when appropriate, reply with one or more SIP response messages identified by the following status codes:

1xx Provisional indicates that the request has been successfully received, and it is in the process of processing the request. For example, 100 Trying, 180 Ringing.

2xx Success indicates the successful completion of the action requested. For example, 200 Ok.

3xx Redirection indicates that the request needs to be redirected to someone else. For example, 301 Moved Permanently, 302 Moved Temporarily.

4xx Client Error indicates that the request is invalid. For example, 404 Not Found, 410 Gone, 403 Forbidden.

5xx Server Error indicates that the server cannot fulfill certain valid request. For example, 503 Service Unavailable.

6xx Global Failure indicates that the request cannot be fulfilled at any server. For example, 600 Busy Everywhere.

Figures 2 and 3 show the INVITE and 200 OK messages of a call from a PSTN phone (703-xxx-9398) to our AT&T VoIP phone (703-xxx-0461). The sample SIP messages include important fields such as To, From, CSeq, Call-ID, Max-Forward, Via, Request-URI, and Contact as well as part of the message body. Specifically, the message body part of the INVITE and 200 OK messages includes the IP addresses and UDP port numbers that the caller and callee choose to use for the upcoming real-time transport protocol (RTP) voice stream. Figure 2 shows that the caller is expecting to receive RTP voice stream from the callee at IP address 12.194.224.134 on port 22148. Figure 3 shows that the callee is expecting to receive RTP voice stream from the caller at IP address 192.168.1.188 on port 10000.

Clients on a client/server network share their resources directly with each other.

Fig. 2. An example of SIP INVITE message.

Clients on a client/server network share their resources directly with each other.

Fig. 3. An example of SIP 200 OK message.

Read full chapter

URL: https://www.sciencedirect.com/science/article/pii/B978012385514500001X

Asynchronous Transfer Mode: An Emerging Network Standard for High-Speed Communications

Ronald J. Vetter, in Advances in Computers, 1997

3.1.3 LANE Components

LANE follows a client/server model, in which multiple LANE clients (LECs) connect to LANE servers. LANE defines three different types of servers: LANE Server (LES), Broadcast and Unknown Server (BUS), and the LANE Configuration Server (LECS) [2,6] (see Fig. 15). The LES is responsible for resolving MAC addresses to ATM addresses, the BUS is responsible for flooding multicast and unicast packets with unknown destination ATM addresses among LECs on an emulated LAN, and the LECS provides functions necessary for configuring LECs with the addresses of the LES used by the attached emulated LAN.

Clients on a client/server network share their resources directly with each other.

Fig. 15. LANE components and protocol interfaces.

Every Ethernet or token ring LAN station has an associated LEC that is used to handle ATM transfers. When a station on a traditional LAN segment wants to send data to another station on another segment, over an ATM backbone network, it uses its LEC to transfer/receive data over the ATM part of the path. That is, suppose a sending station wants to send a LAN frame to another station located on the other side of an ATM network. The LEC sends the LES a MAC ATM address resolution query containing the target station’s MAC address. The LES responds with the ATM address of the LEC that is associated with the target station. The originating LEC then sets up an ATM switched virtual circuit, converts the MAC frames to ATM cells, and transmits the cells over the network. At the receiving LEC, the ATM cells are converted to MAC frames and forwarded to the receiving station.

Although Fig. 15 depicts the various LANE components as separate entities from the ATM network, in practice the LES, BUS, and LECS are typically software components located in the ATM switch, rather than in stand-alone host computers. The LEC component is required to be in every ATM host and device attached to the ATM network.

Read full chapter

URL: https://www.sciencedirect.com/science/article/pii/S0065245808603411

Application Layer Protocols

Edward Insam PhD, BSc, in TCP/IP Embedded Internet Applications, 2003

SMTP

The simple mail transfer protocol (SMTP) is defined in RFC 821, and is used for simple e-mail transmission; SMTP can only be used to transmit mail. A different protocol, post office protocol 3 (POP3) is required for more advanced operations such as receiving, deleting, enumerating and managing mail items. Most ISPs provide both SMTP and POP3 hosting services on their dial-up lines.

In order to use e-mail with an ISP, a client must have an e-mail account with the ISP arranged. During a dial-up session, the PPP protocol is used to authenticate the client (by sending its password and user number), and for the server to allocate an IP number to the client, which is valid for the duration of the session. Once the IP connection to the ISP is established, the client opens a TCP connection on port 25, the nominal port allocated to SMTP. Once the TCP link on this port is established, all subsequent two-way communication on the line is via standard NVT-ASCII characters.

Operation follows the standard client–server model, where the client originates a response from the server. Requests are made in the form of SMTP Commands. All commands follow a simple character format structure known as the 822-header format (after the RFC standard that defines it, RFC 822). This format uses standard NVT-ASCII characters delimited by normal carriage return – line feed character pair sequences <CR-LF>. This ‘standard’ text header format is also used in various other Internet application layer protocols. An SMTP transaction is straightforward, and easily implemented on a small micro. The general sequence of operations is as follows:

1.

The caller establishes a TCP connection on port 25 with the host (the caller itself may use for response any port it wishes). The host (ISP) may reply with a welcome text message as follows (note the first three digit number or response code):

220 Sat, 28 Jan 2002 MYISP.COM Mail server. Welcome

2.

The client logs onto the SMTP server by sending the following text string:

HELO myname <CR><LF>

Note the single ‘L’ in ‘HELO’ This is followed by your registered e-mail ‘id’, followed by a single carriage return – line feed pair. Some hosts will require just the id, some others will want your full e-mail address, and some others may just accept the HELO string without a senders address at all, that is:

HELO <CR><LF>

3. The client now needs to wait for a reply. The reply from the server will also be in ASCII form and typically will contain the following message:

250 post – welcome [email protected]

The three-digit number is a unique reply code. The text following it contains the corresponding plain text explanation for human consumption. Client software only needs to check the three digits against a list (full details in the RFC). Code 250 for example is a general OK response. This indicates that the server has accepted the command and that the client can proceed to the next stage. Simple client end software could just respond to 250 codes and ignore the rest, aborting the session otherwise. In any case, the client must wait for a reply before proceeding to the next stage. Not waiting for a response from the server may cause it to ignore the rest of the commands.

4.

On receipt of the correct error code, the client can now send the e-mail message envelope (which contains the sender and recipient addresses). The information in this envelope is required by the server in order to route the message to the final recipient. A typical envelope transaction is as follows:

Clients on a client/server network share their resources directly with each other.

Note that the server acknowledges every line sent individually (returned lines are shown here indented for clarity). The client must wait for every reply before proceeding to the next command. Multiple RCPT TO headers have been used here to show how the same e-mail can be sent to more than one recipient in one session. In a real message, at least one recipient address is required. Note how the server checks every address entry as it arrives, and notifies the sender whether it can or cannot recognise the destination. Many other envelope commands are available, please refer to the RFC for more information. The last line of the envelope contains the command DATA on its own. This tells the server that any text following this command will be the body of the text message.

5.

The client can now send the text of the message. It is common practice to add a message header at the beginning of the message body. Message headers are used by receivers and browsers to classify message received and for displaying to remote users. They are not strictly necessary, and they do not need to be present for a message to reach its destination.

Clients on a client/server network share their resources directly with each other.

Clients on a client/server network share their resources directly with each other.

The FROM command is followed by the common name and the e-mail address of the sender. They could be anything you like; they are only used for display purposes as the host will simply pass them on without processing. The second header command TO, takes the common name and the e-mail address of the recipient. Again, this information is used by the recipient's browser or e-mail manager, and not processed by the mail system. The SUBJECT line can be used to carry optional header information, which may be of use to a recipient browsing through a long list of incoming mail messages. Information on headers can be very confusing and misleading as every computer in the chain may append its own piece of text to the header. This is done so that a recipient can track the sequence of events back to the sender. Unfortunately, misleading information can be added to headers by spammers to confuse the recipient as to who the original sender was. The body text follows the headers next. It is common practice to send text in plain 7-bit ASCII. It is also possible to encode sections of text in different character formats by using MIME type encoding. This allows the inclusion of characters in non-standard character sets, special punctuation marks and special symbols. Computer or graphics files can also be sent as attachments, where text or binary files are converted using compression and other encoding algorithms into character sets compatible with NVI-ASCII, without including characters that may upset transmission. RFC 1522 specifies one way of sending non-ASCII characters in RFC 822 message headers. The main use of this is to allow additional characters in the sender and receiver names, and in the subject lines. With this method, encoded characters are sent as multiple-character encoded sequences, for example, the sequence =?ISO-8859-1?Q?Andr=E9? = results in the text André (note the addition of an accent in the last letter). The text after the first question mark ISO-8859-1 specifies one of many character sets to be used (valid values are ‘us-ascii’ and ‘iso-8859-X’ where X is a single digit, as in ISO-8859-1), Q denotes ‘quoted printable’ that is, characters are sent as the combination of the character ‘=’ followed by two hexadecimal digits corresponding to the wanted character position in the relevant table. For example, the character é (accented e), corresponding to the 8-bit character 0xE9, is sent as the sequence ‘=E9’ Spaces can be sent as an underscore or the three character sequence ‘=20’. The British pound currency sign is sent as ‘=A3’ An alternative to Q is B, which means base-64 encoding. In base-64 encoding, three consecutive bytes of original text (24 bits) are encoded as four 6-bit values. The 6-bit values are mapped to a standard ASCII table of numbers and upper/lower case letters. In this way, text and data composed of 8-bit characters can be sent as a limited character set.

Multipurpose Internet mail extensions (MIME) encoding is covered in RFC 1521. This applies mainly to the body of the text (as opposed to the headers). The purpose of MIME is to add extensions, in the form of command lines, to the body of a mail message to add some form of structure to it. In practice, MIME just adds some new RFC-822 style headers to the text, telling the recipient the structure of the body to follow. RFC-1522 encoding is normally applied to ensure the body is transmitted using plain ASCII (NVT ASCII) characters in case some of the original material contains 8-bit data (i.e. binary files or images). A typical set of MIME headers are:

Clients on a client/server network share their resources directly with each other.

More information on character and graphic encoding can be found in the respective RFCs. The last item of body text must have a full stop (period) character in a line of its own. That is, the termination sequence <CR><LF><.><CR><LF> notifies the server that the message text is completed and message transmission is over.

6.

The client now waits for the host to send an acknowledge message. The reply will usually contain a unique message number

250 submitted and queued (msg.12345678)

7.

The client can now close the e-mail session, close the TCP connection, or attempt to send another e-mail message if needed. The client does this by sending the QUIT command on a line of its own:

Clients on a client/server network share their resources directly with each other.

Tables 8-3 and 8-4 give a list of SMTP commands and reply codes, respectively.

Table 8-3. List of SMTP commands

CommandArgumentDescription
HELO Sender's host name Used for logging on
MAIL Sender of message Used to identify the sender and therefore define the revere path back to the sender (also MAIL FROM)
RCPT Intended recipient The forward path to one or more final recipients
DATA Body of message Message is terminated with a full stop on a single line of text
SEND Intended recipient Used to initiate a mail message that should be delivered directly to a user if they are currently logged on to the system
RSET The current mail transaction should be aborted, and that any stored messages should be deleted
VRFY Recipient to be verified Used to confirm the identity of the user passed as an argument, this can be used to check if the user actually exists in the hosts list.
NOOP Used to solicit an OK response from the remote
QUIT Specifies that the host should send an OK response, and then close the communications channel.
TURN Command the host to return an OK reply and then reverse the roles of the machines in order to send mail the other way

Table 8-4. SMTP reply codes (please refer to RFC 821 for complete definitions)

CodeDescription
211 System status or system help reply
214 Help message
220 Service ready
221 Service closing transmission channel
250 OK, service action accepted
251 User is not local, will forward to given path
354 Start mail text input
421 Service not available – closing communications channel
450 Requested action not taken, mailbox unavailable
451 Requested action not taken, local error in processing
452 Requested action not taken, insufficient storage
500 Syntax error – command unrecognized
501 Syntax error in parameters or arguments
502 Command not implemented
503 Bad sequence of commands
504 Command parameter not implemented

Read full chapter

URL: https://www.sciencedirect.com/science/article/pii/B9780750657358500357

Interpreting Results

Russ Rogers, in Nessus Network Auditing (Second Edition), 2008

The Nessus UI Basics

Nessus works on a client–server model.

There are currently two open-source GUI clients available—Nessus Client for Windows and the Nessus Client for X. They are nearly exact.

There is also a UNIX command-line client that is not discussed in this chapter.

Both GUI clients discussed allow one to view scanner output, save and export reports in various formats, and import results from previously saved reports.

Regardless of the client used, the Nessus scanner reports are detailed and complex and need to be carefully analyzed to be fully understood.

Read full chapter

URL: https://www.sciencedirect.com/science/article/pii/B9781597492089000058

Introducing Nessus

Russ Rogers, in Nessus Network Auditing (Second Edition), 2008

Basic Components

The Nessus Project adopted a client/server model for its foundation. This client/ server model allows the security analyst to “detach” from the vulnerability scan and use his resources for other items while Nessus continues to do what it does best.

The Nessus client can connect to the nessusd server in many ways that employ both encryption and authentication.

The Nessus Attack Scripting Language (NASL) allows security analysts to quickly create their own plugins for vulnerability checks.

The Knowledge Base allows Nessus to share data gleaned from one plugin with the processes of another plugin. In this way, each plugin builds upon previously executed plugins.

Read full chapter

URL: https://www.sciencedirect.com/science/article/pii/B9781597492089000022

Introduction

John F. Buford, ... Eng Keong Lua, in P2P Networking and Applications, 2009

Barrier to Entry

Compare the costs of the client/server model with the P2P model for launching a new network application. For a number of significant applications, the relative software complexity is comparable. For large user populations, client/server requires a server farm, that is, a set of server-class hosts maintained in a data center with sufficient network capacity to carry the aggregated traffic from all the clients to the servers. For fault tolerance, the server farm is typically replicated at multiple locations. The servers are managed to provide 24 × 7 service. The servers are also monitored for faults, security, and utilization versus capacity.

In the P2P model there are no server farms. The client machines or end systems contribute resources. Systems are not managed. Service quality may be low. In real P2P deployments, servers can be used to download the initial client software, support the bootstrapping of the P2P overlay, and provide user account registration. These servers are typically modest in terms of costs compared to the server farms.

Read full chapter

URL: https://www.sciencedirect.com/science/article/pii/B9780123742148000015

The Information Integration System K2

Val Tannen, ... Scott Harker, in Bioinformatics, 2003

8.7 USER INTERFACES

K2 has been developed using a client–server model. The K2 server listens for connections either through a socket or through Java RMI. It is easy to develop a client that can connect to K2 through one of these paths, issue queries, and receive results. Three basic clients come with K2: a text-based client, an RMI client, and one that runs as a servlet.

The interactive, text-based client connects to a K2 server through a socket connection. It accepts a query in OQL through a command-line-style interface, sends it to the server, gets the result back as formatted text, and displays it; then it waits for the next query to be entered. This simple client generally is used to test the socket connection to K2 and to issue simple queries during the development process. It is not intended to be an interface for end users.

The other type of user connection is through RMI. These connections are capable of executing multiple queries at once and can halt execution of queries in progress. This is the connection method that K2 servers use to connect to other K2 servers to distribute the execution of a query.

There is a client that makes an RMI connection to a K2 server with administrator privileges. The server restricts these connections to certain usernames connecting from certain IP addresses and requires a password. Currently, an administrator can examine the state of the server, add and remove connections to individual drivers, stop currently running queries, disconnect clients, and bring the server to a state where it can be stopped safely. More functionality is planned for administrators in the future.

A client that runs as a servlet is also included with K2. Using code developed at the Computational Biology and Informatics Laboratory (at the University of Pennsylvania), this servlet allows entry of ad hoc K2 queries and maintains the results for each username individually.

A major component of any user interface is the representation of the data to the user. As exemplified previously, a user (perhaps one serving a larger group) can define in K2MDL a transformed/integrated schema for a class of users and applications and can specify how the objects of this schema map to the underlying data sources. Users of this schema (called an ontology by some) can issue vastly simplified queries against it, without knowledge of the data sources themselves.

Read full chapter

URL: https://www.sciencedirect.com/science/article/pii/B9781558608290500103

When network clients share resources with each other this type of network is called?

In its simplest form, a peer-to-peer (P2P) network is created when two or more PCs are connected and share resources without going through a separate server computer.

Can a client

A client-server file-sharing program stores files in a server and sends them to users upon request. This type of model can take several different forms. File transfer protocol (FTP) is an example of a client-server file-sharing program. With FTP, you can send files to and from different devices over the internet.

What is true about a client

What is true about a client-server network? In a client-server network, a dedicated server responds to service requests from clients. The roles of client and server are not shared on each host in the network. In a peer-to-peer network, computers are connected via a network and can share resources.

What provides access to resources and services in a client

In client/server networks, users store their files on a central computer from which files are accessed directly. In the client/server network, the server is the central computer that stores the information, and the client is the computer (and user) that accesses the information from that central computer.