1.

1 CLIENT/SERVER Client-server is a computing architecture which separates a client from a server, and is almost always implemented over a computer network. Each client or server connected to a network can also be referred to as a node. The most basic type of client-server architecture employs only two types of nodes: clients and servers. This type of architecture is sometimes referred to as two-tier. It allows devices to share files and resources. 1.1.1. CHARACTERISTICS OF A CLIENT

Request sender is known as client Initiates requests Waits for and receives replies. Usually connects to a small number of servers at one time Typically interacts directly with end-users using a graphical user interface

1.1.2. CHARACTERISTICS OF A SERVER

Receiver of request which is send by client is known as server Passive (slave) Waits for requests from clients Upon receipt of requests, processes them and then serves replies Usually accepts connections from a large number of clients Typically does not interact directly with end-users

1.1.3. CLIENT/SERVER COMPUTING ERA Client/Server computing is an irresistible movement that is reshaping the way computers are being used. Although this computing movement is relatively young, it is already in full force and is not leaving any facet of the computer industry untouched. Internet is introducing a new form of client/server computing called Intergalactic Client/Server.

1.1.4. WHATS THE REAL CLIENT/SERVER VISION? Client/Server computing has the unique distinction of having strong champions across the entire spectrum of the computer industry. The PC can do it all crowd, Client/Server computing means scrapping every mainframe that cant fit on the desktop and the demise of host-centric computing. For mainframe diehards, client/server computing means unleashing a new breed of born-again networked mainframes that will bring every PC in the enterprises back to the fold. There is some truth in all these visions : Client/Server Computing provides an open and flexible environment where mix and match is the rule. The Client applications will run predominantly on PCs and other desktop machines that are at home an LANs. Servers know exactly how to communicate with their PC client. Mainframes to succeed as servers, however, they will learn how to meet PCs as equals on the LAN. In this world of equals, mainframe servers cannot treat PCs as dumb terminals. 1.1.5. CLIENT/SERVER AND THE NEW IS Client/Server application development requires hybrid skills that include transaction processing, database design, communication experience, and graphical user interface savvy. The more advanced applications requires a knowledge of distributed objects and the Internet. Mastering this skills will require renaissance programmers who can combine the best of big-iron, reliability driven thinking with PC LAN tradition. IS departments have the skills to not only manage and deploy large networks but also to provide interoperability standards. They also know now to fine-tune applications, distribute fixes, and ensure data integrity.

 IS traditionally caters to the large data centers-not to the line departments that own the PCs and LANs. Client/Server computing may be by 2 tiered IS Organizations: Line IS Enterprise IS Line IS For managing and deploying departmental Systems. Enterprise IS For managing the global network and setting interoperability standards.

1.1.6. COMPETITION IN THE CLIENT/SERVER MARKET Client/Server, the great equalizer of the computer business, encourages openness and provides a level playing field on which a wide variety of client and server platforms can participate. The open/server environment serves as the catalyst for commoditizing hardware and system software.

The PC is a good example of a computer commodity; it can be obtained from multiple suppliers and is sold in very price-competitive market solutions.

LAN adapters, LAN protocol stacks, network routers, and brides are also becoming commodities. On the software side, PC operating systems, SQL Database Management Systems, and Web Servers and Browsers are approaching commodity status.

CORBA, Network OLE, and the Distributed Computing Environment will make instant commodities out of distributed objects, network directory software, security services, and system management. These trends are good news for computer users.

Computer vendors will in the short run differentiate themselves by the power of the superservers they provide. PCs and Client/Server solutions will unleash a massive new wave of computerization.

Clients will be everywhere. They will come in all shapes and forms including desktops, palmtops, pen tablets, robots, Internet PCs etc. This bullish view of the industry puts us in the camp of those who believe that the supply of low-cost MIPs creates its own demand.

1.1.7. CLIENT/SERVER CHARACTERISTICS Service Shared resources Asymmetrical protocols Transparency of location Mix and Match Message-based exchanges Encapsulation of services Scalability Integrity

Service Client/Server is primarily a relationship between processes running on separate machines. The Server process is a provider of services. The Client is a consumer of services. In essence, client/server provides a clean separation of function based on the idea of service.

Shared Resources A server can service many clients at the same time and regulate their access to shared resources.

Asymmetrical Protocols There is a many-to-one relationship between clients and server. Clients always initiate the dialog by requesting a service. Servers are passively awaiting requests from the clients.

Transparency of Location The Server is a process that can reside on the same machine as the client or on a different machine across a network. Client/Server software usually masks the location of the server from the clients by redirecting the service calls when needed. A program can be client, a server, or both.

Mix and Match The ideal client/server software is independent of hardware or operating system software platforms. Should be able to mix and match client and server platforms.

Message-based Exchange Clients and Servers are loosely coupled systems that interact through a message passing mechanism. The message is the delivery mechanism for the service requested and replies.

Encapsulation of Services The Server is a specialist. A message tells a server what service is requested; it is then up to the server to determine how to get the job done. Servers can be upgraded without affecting the clients as long as the published message interface is not changed.

Scalability Client/Server systems can be scaled horizontally or vertically. Horizontal Scaling means adding or removing client workstations with only a slight performance impact. Vertical Scaling means migrating to a larger and faster server machine or multiservers.

Integrity The server code and server data is centrally maintained, which results cheaper maintenance and the guarding of shared data integrity. At the same time, the clients remain personal and independent. Server Types 1. File Server 2. Database Server 3. Transaction Server 4. Groupware Server 5. Object Server 6. Web Server 1.2. File Servers

The client passes requests for file records over a network to the file server. This is a very primitive form of data service. File Servers are useful for sharing files across a network. These are acting as a repository of documents, images, engineering drawings and other large data objects.

1.3. Database Servers

The client passes SQL requests as messages to the database server. The result of each SQL command are returned over the network to the client. The code in the server process will processes the SQL request and the data reside in the same machine.

Distributed database servers may increase the efficiency of the processing power. These servers provide the foundation for decision-support systems that require adhoc queries and flexible reports.

1.4. Transaction Servers

The client invokes remote procedures that reside on the server with an SQL database engine.

These remote procedures on the server execute a group of SQL statements. The network exchange consists of a single request/reply message. The SQL statements either all succeed or fail as a unit. These grouped SQL statements are called Transactions.

The server component usually consists of SQL transactions against a database

These are called Online Transaction Processing or OLTP. OLTP applications also require tight controls over the security and integrity of the database.

Two forms of OLTP: based on the TP Monitors provided by the OLTP Vendors
o o

TP Lite TP Heavy

1.5. Groupware Servers

Groupware addresses the management of semi-structured information such as text, image, mail, bulletin boards, and the flow of work.

These client/server systems place people in direct contact with other people. Lotus Notes is the Leading Example. In most cases, applications are created using a scripting language and form-based interfaces provided by the vendor.

The communication middleware between the client and the server is vendorspecific.

1.6. Object Servers

The client/server application is written as a set of communicating objects. Client objects communicate with server objects using an Object Request Broker (ORB).

The client invokes a method on a remote object. The ORB locates an instance of that object server class, invokes the requested method, and returns the results to the client object.

Server objects must provide support for concurrency and sharing. The ORB brings it all together. Example: Digitals Object Broker, IBMs SOM 3.0, Suns NEO, HPs ORB Plus, Expersofts Power Broker, Microsofts DCOM or Network OLE.

1.7. Web Servers

WWW is the first truly intergalactic client/server application. This model of client/server consists of thin, portable, universal clients that talk to Superfast Servers.

The clients and servers communicate using an RPC-like protocol called HTTP. This protocol defines a simple set of commands, parameters are passed as strings. The collection of HTML documents are stored in the Web Server.

1.8. WHAT IS MIDDLEWARE?

Middleware does not include the software that provides the actual service thats in the servers domain. It also does not include the user interface or the applications logic thats in the clients domain.

It starts with the API set on the client side that is used to invoke a service, and it covers the transmission of the request over the network and the resulting response.

Middleware

divided

into

two

broad

classes:

(a) General Middleware (b) Service-Specific Middleware 1.9. GENERAL MIDDLEWARE

It is the substrate for most client/server interactions It includes the communication stacks, distributed directories, authentication stacks, distributed directories, authentication services, network time, remote procedure calls, and queuing services.

Products that fall into the general middleware category include DCE, ONC+, NetWare, NamedPipes, LAN Server, LAN Manager, Vines, TCP/IP, APPC and NetBIOS.

Message Oriented Middleware (MOM) products from Peerlogic, Covia, Message Express, System Strategies and IBM.

These are depends on message queue system and increases portability, interoperability, flexibility.

1.10. SERVICE-SPECIFIC MIDDLEWARE

It is need to accomplish a particular client/server type of service. This includes

o

Database-specific middleware such as ODBC, DRDA, EDA/SQL, SAG/CLI and Oracle Glue.

OLTP-specific middleware such as Tuxedos ATMI and /WS, Encinas Transactional RPC, and X/Opens TxRPC and XATMI

Groupware-specific middleware such as MAPI, VIM, VIC, SMTP and Lotus Notes Calls Object-specific middleware such as OMGs CORBA and Microsofts Network OLE (or DCOM)

o o

Internet-specific middleware such as HTTP, S-HTTP and SSL System Management-specific middleware such as SNMP, CMIP and ORBs.

1.10.1. FAT SERVER / FAT CLIENTS C/S applications can also be differentiated by how the distributed application is split between client and server. FAT SERVER Fat Server Model places more function on the server. These applications are easier to manage and deploy on the n/w because most of the codes are runs on the servers. Its try to minimize n/w interchange by creating more abstract levels of service. Instead of exporting the raw data, they exports the procedures that operates on that data Eg : Groupware, Transaction and Web Servers are Fat Servers. FAT CLIENT Fat Client Model does the reverse. Fat clients are the more traditional form of c/s. The bulk of the application runs on the client side of the equation. These are used for decision support and personal software. They provide flexibility and opportunities for creating front-end tools that let endusers create their own applications. Eg: Database and File Servers are Fat Clients

1.10.2. 2-Tier Vs 3-Tier

Instead of Fat clients and fat servers these terms can be used. It is all about how you split the client/server applications into functional units. These functional units can be assigned to either the client or to one or more servers. The most typical functional units are: User Interface Business Logic and the Shared Data In 2-tier, the application logic is either buried inside the User Interface on the client or within the database on the server (or both) 2-tier system examples: File Servers and Database Servers with stored procedure. In 3-tier, the application logic (or) process lives in the middle-tier, it is separated from the data and the user interface. 3-tier systems are more scalable, robust and flexible. In addition, they can integrate data from multiple sources. Examples: TP Monitors, Distributed Objects and the Web.

1.10.3. INTERGALACTIC CLIENT/SERVER Intergalactic client/server is a new threshold of client/server applications and this is because of 1. the exponential increase of low-cost bandwidth on Wide Area Networks for example, the Internet and CompuServe 2. a new generation of network-enabled, multi-threaded desktop operating systems for example, OS/2 Warp Connect and Windows 95. This new threshold marks the beginning of a transition from Ethernet client/server to intergalactic client/server that will result in the irrelevance of proximity.

The center of gravity is shifting from single-server, 2-tier, LAN-based departmental client/server to a post-scarcity form of client/server where every machine on the global information highway can be both a client and a server. Application characteristics Number of clients per application Number of servers per application Geography Server-to-server Interactions Middleware Client/server architecture Transactional updates Multimedia content Mobile Agents Client front-ends Intergalactic Era client/server Millions 100,000+ Global Yes ORBs on top of Internet 3-tier (or n-tier) Pervasive High Yes OOUIs, compound documents, and shippable places 1997 onwards Ethernet Era client/server Less than 100 <5 Campus-based No SQL and stored procedure 2-tier Very infrequent Low No GUI

Time-frame

1985 till present

The major key technologies in intergalactic client/server model are: a) Rich transaction Processing supports the nested transactions that span across multiple servers, long-lived transactions that executes over long periods of time as they travel from server to server, and queued transactions that can be used in secure business-

to-business dealings. Most nodes on the network participates in the secured transaction; super-server nodes handle the massive transaction loads. b) Roaming agents the environment is populated with all types of agents. This agent technology includes cross-platform scripting engines, workflow, and Java-like mobile code environments that allow agents to live on any machine on the network. c) Rich data management This includes active multimedia compound documents that can move, store, view and edit in-place anywhere on the network. Most nodes on the network provides compound document technology for example, OLE or OpenDoc-for mobile document management. d) Intelligent self-managing entities With the introduction of new multi-threaded, high-volume, network-ready desktop operating systems, increased the workload on the server operating system. This type of distributed software knows how to manage and configure itself and protect itself against threats. e) Intelligent Middleware -The distributed environment must provide the semblance of a single system-image across potentially millions of hybrid client/server machines. The middleware creates this illusion by making all servers on the global network appear to behave like a single computer system. Users and programs should be able to dynamically join and leave the network, and then discover each other.

1.11. CLIENT/SERVER BUILDING BLOCKS

CLIENT/SERVER : A ONE SIZE FITS ALL MODEL The building blocks of client/server applications are: 1. Client 2. Middleware 3. Server

These building blocks can be rearranged to use them in the following situations: 1. Client/Server for tiny shops and nomadic tribes This is a building-block implementation that runs the client, the middleware software, and most of the business services on the same machine. It is the suggested implementation for the one-person shops, home offices, and mobile users with well-endowed laptops. 2. Client/Server for small shops and departments - This is the classic Ethernet client/single-server, building block implementation. It is used in small shops, departments, and branch offices. This is the predominant form of client/server today. 3. Client/Server for intergalactic enterprises This is the multiserver building-block implementation of client/server. The servers present a single system image to the client. They can be spread out throughout the enterprise, but they can be made to look like they are part of the local desktop. This implementation meets the initial needs of intergalactic client/server computing.

4. Client/Server for a post-scarcity world This model transforms every machine in the world into both a client and a server. Personal agents on every machine will handle all the negotiations with their peer agents anywhere in the universe. This dream is almost within reach.

1.11.2. Client/Server for Tiny Shops and Nomadic Tribes

It is easy to run the client and server portion of an application on the same machine.

Vendors can easily package single-user versions of a client/server application. The business critical client/server application runs on one machine and does some occasional communications with outside servers to exchange data, refresh a database and send or receive mail and faxes. Ex: Internet.

1.11.3. Client/Server for small shops and departments

The client/server architecture is particularly well-suited for the LAN-based single server establishments.

It consists of multiple clients talking to a local server.

This is the model used in small businesses. The single-server nature of the model tends to keep the middleware simple. The client only needs to look into a configuration file to find its servers name. Security is implemented at the machine level and kept quite simple. The network is usually relatively easy to administer; its a part-time job for a member of the group.

There are no complex interactions between servers, so it is easy to identify failures- theyre either on the client or on the local server.

1.11.4. Client/Server for Intergalactic Enterprises:

The client/server enterprise model addresses the needs of establishments with a mix of heterogeneous servers.

These models are upwardly scalable. When more processing power is needed for various intergalactic functions, more servers can be added, or the existing server machine can be traded up for the latest generation of superserver machine.

The servers can be partitioned based on the function they provide, the resource they control, or the database they own.

The servers can be replicated to provide a fault-tolerant service or to boost an applications performance.

Multiserver capability, when properly used, can provide an awesome amount of compute power and flexibility, in many cases rivaling that of mainframes.

To exploit the full power of multiservers, we need low-cost, high-speed bandwidth and an awesome amount of middleware features -including
o o o o

network directory services network security remote procedure calls and network time services.

Middleware creates a common view of all the services on the network called a single system image.

Good

software

architecture

for

intergalactic

enterprise

client/server

implementations is all about creating system ensembles out of modular building blocks.

Intergalactic client/server is the driving force behind middleware standards as distributed objects and the Internet.

1.11.5. Client/Server for a Post-Scarcity World

Every machine is both a client and a full-function server. Because every machine is a full-function server, it will run, at a minimum, a file server, database server, workflow agent, TP Monitor, and Web server all connected via an ORB.

This is in addition to all the client software and middleware. In next few years, a hundred million machines or more may be running almost all the forms of client/server software

In this model instead of mobile agents, personal agents will be used.

1.11.6. INSIDE THE BUILDING BLOCKS

The Client Building Block

Runs the client side of the application It runs on the OS that provides a GUI or an OOUI and that can access distributed services, wherever they may be.

The client also runs a component of the Distributed System Management (DSM) element.

The Server Building Block

Runs the server side of the application The server application typically runs on top of some shrink-wrapped server software package.

The five contending server platforms for creating the next generation of client/server applications are SQL database severs, TP Monitors, groupware servers, Object servers and the Web server.

The server side depends on the OS to interface with the middleware building block.

The server also runs DSM component It may be a simple agent or a shared object database etc.

The Middleware Building Block

Runs on both the client and server sides of an application This broken into three category
o o o

Transport Stacks NOS Service-specific middleware

Middleware is the nervous system of the client/server infrastructure This also has the DSM component

DSM

Runs on every node in the client/server network. A managing workstation collects information from all its agents on the network and displays it graphically.

The managing workstation can also instruct its agents to perform actions on its behalf.

Server-to-server Middleware

Server-to-server interactions are usually client/server in nature servers are clients to other servers.

However, some server-to-server interactions require specialized server middleware. For example, Two-Phase commit protocol may be used to coordinate a transaction that executes on multiple servers.

Servers on mail backbone will use special server-to-server middleware for doing store-and-forward type messaging.

But most modern software follows the client/server paradigm.

1.12. REMOTE PROCEDURE CALL

RPCs are not procedure calls at all, they are truly process invocations. The invoked program runs across the wire in a different resource domain

A client process calls a function on a remote server and suspends itself until it gets back the results.

Parameters are passed like in any ordinary procedure. The RPC, like an ordinary procedure is synchronous. The process (or threads) that issue the call waits until it gets the results. Under the covers, the RPC run-time software collects values for the parameters, forms a message, and sends it to the remote server.

The server receives the request, unpacks the parameters, calls the procedure, and sends the reply back to the client.

While RPCs make life easier for the programmer, they pose a challenge for the NOS designers who supply the development tools and run-time environments.

The Common issues are:

How are the Server functions located and started?

Server starts the process, when a remote invocation is received with necessary parameters and returns the response to the client.

What happens when multiple clients invoke the same function? Now an environment is needed to start and stop servers, prioritize requests, perform security checks, and provide some form of load-balancing.

Each incoming requests invokes a thread in the server side. A server loop is created to manage the pool of threads waiting for work rather than create a thread for each incoming request.

TP Monitors are really need on the server side, which provides more functions than a NOS.

How are parameters defined and passed between the client and the server?

The better NOSs provide an Interface Definition Language (IDL) for describing the functions and parameters that a server exports to its clients.

An IDL compiler takes these descriptions and produces source code stubs (and header files) for both the client and server.

These stubs can then be linked with the client and server code. The client stubs packages the parameters in an RPC packet, converts the data, calls the RPC run-time library and waits for the servers reply.

On the server side, the server stubs unpacks the parameters, calls the remote procedure, packages the results, and sends the reply to the client.

How are failures handled?

Both the sides of the RPC can fail separately, it is important for the software to be able to handle all the possible failure combinations.

If the server does not respond, the client side will normally block, timeout, and retry the call.

The server side must guarantee only once semantics to make sure that a duplicate request is not re-executed.

If the client unexpectedly dies after issuing a request, the server must be able to undo the effects of that transition.

How is security handled by the RPC?

Modern NOSs, like DCE make it easy to automatically incorporate their security features into the RPC.

All you need to specify is the level of security required; then the RPC and security feature will cooperate to make it happen.

How does the client find its server?

The association of a client with a server is called binding. The binding information may be hardcoded in the client. The client can find its server by consulting a configuration file or an environment parameter.

A client can also find its server at run time through the network directory services. The server must, of course, advertise their services in the directory.

The process of using the directory to find a server at runtime is called dynamic binding

RPC can be used to find a server. The RPC client stub will locate a server from a list of servers that support the interface. This is called automatic binding.

How is data representation across systems handled?

The problem here is that different CPUs represent data structures differently (Ex: bigendian Vs little endian)

To maintain machine independence, the RPC must provide some level of data format translation across systems.

Example: Sun RPC requires that clients convert their data to a neutral canonical format using the External Data Representation (XDR) APIs. In contrast, DCEs Network Data Representation (NDR) service is multicanonical, meaning that it supports multiple data format representations.

The client chooses one of these formats, tags the data with chosen format, and then leaves it up to the server to transform the data into a format it understands.

In other words, the server makes it right. It lets the client to do translation, which makes the life easy for the server.

With Sun, all clients look the same to the server: The Client makes it right.

1.13. Messaging and Queuing : The MOM Middleware

MOM is a key piece of middleware that is absolutely essential for a class of client/server products.

If the application can tolerate a certain level of time-independent responses, MOM provides the easiest path for creating enterprise and inter-enterprise client/server systems.

This accumulates outgoing transactions in queue and do a bulk upload when a connection can be established with an office server.

MOM allows general purpose messages to be exchanged in a client/server system using message queues.

Applications communicate over networks by simply putting messages in queues and getting messages from queues.

MOM hides all the nasty communications from applications and typically provides a very simple high-level of API to its services.

A MOM consortium was formed in mid-1993 with the goal of creating standards for messaging middleware.

Members are product providers including

o o o o o

IBM MQSeries Covia Communications Integrator Peerlogic PIPES Horizon Strategies Message Express System Strategies ezBridge

MOMs messaging and queuing allows clients and servers to communicate across a network without being linked by a private, dedicated, logical connection.

The clients and servers can run at different times. Everybody communicates by putting messages on queues and by taking messages from queues.

MOM products provide their own NOS services including hierarchical naming, security, and a layer that isolates applications from the network.

They use virtual memory on the local OS to create their queues. Most messaging products allow the sender to specify the name of the reply queue. The products also include some type of format field that tells the recipient how to interpret the message data.

MOM enabled programs do not talk to each other directly, so either program can be busy, unavailable, or simply not running at the same time.

The target program can even be started several hours later.

Many clients are sending requests to one server queue.

The messages are picked off the queue by multiple instances of the server program that are concurrently servicing the clients.

The server instances can take messages off the queue either on a FIFO basis or accounting to some priority to load-balancing scheme.

The message queue can be concurrently accessed. The servers can also use messaging filters to throw away the messages they dont want to process, or they can pass them on to other servers.

The MOM messaging products provide persistent (logged on disk) and nonpersistent (in memory) message queues.

Persistent messages are slower, that they can be recovered in case of power failures after a system restart.

A message queue can be local to the machine or remote. System administrators can usually specify the number of messages a queue can hold and the maximum message size.

1.13.1. MOM Vs RPC

Feature Metaphor Client/Server time relationship MOM Post-office like Asynchronous. Clients and Servers may operate at different times and speeds RPC Telephone like Synchronous. Clients and Servers must run concurrently. Servers must keep up with clients. Servers must first come up before clients can talk to them. Call-Return Yes

Client/Server Sequencing

No fixed sequence

Style

Queued

Partners need to be No available Load-balancing

Single queue can be used Requires a separate TP to implement FIFO or Monitor. priority based policy Yes (Some Products) No. Requires a Message Queue can Transactional RPC. participate in the commit synchronization Yes Slow. An intermediate hop is required No Fast

Transactional Support

Message Filtering Performance

Asynchronous processing

Yes. Queues and triggers Limited. Requires are required threads and tricky code for managing threads.

1.14. PEER TO PEER COMMUNICATIONS

Most early client/server applications were implemented using low-level, conversational, peer-to-peer protocols such as sockets, TLI, CPIC/APPC, NetBIOS and Named Pipes.

These low-level protocols are hard to code and maintain. Instead now, the programmers are using RPCs, MOMs, and ORBs, which provide high level abstraction. The term, peer-to-peer indicates that the two sides of a communication link use the same protocol interface to conduct a networked conversation. The protocol is symmetrical, and it is sometimes called program-to-program. The peer-to-peer interface not fully mask the underlying network from the programmer.

Programmer have to handle the transmission timeouts, race conditions, and other network errors.

The peer-to-peer protocols started as stack-specific APIs.

1.14.1. Sockets

Sockets were introduced in 1981 as the UNIX BSD 4.2 generic interface that would provide Unix-to-Unix communications over network.

In 1985, SUN OS introduced NFS and RPC over sockets. Sockets are supported on virtually every OS. The windows socket API, known as WinSock, is a multivendor specification that standardizes the use of TCP/IP under windows.

In BSD Unix System, sockets are part of the Kernel and provide both a standalone and networked IPC service.

Socket = Net_ID . Host_ID . Port_ID = IP Address + Port Address.

The three most popular socket types are

o o o

Stream Datagram Raw

Stream and datagram sockets interface to the TCP and UDP protocols, and raw sockets interface to the IP protocol.

A port is an entry point to an application that resides on the host. It is represented by a 16-bit integer. Ports are commonly used to define the entry points for services provided by the server applications.

1.14.1.1. Datagrams Vs Sessions

Connection-oriented protocols also known as session-based protocols, virtual circuits or sequenced packet exchanges provide a reliable two-way connection service over a session.

Each packet of information gets exchanged over a session. Duplicate packets are detected and discarded by the session services. Overhead associated with creating and managing the session. If a session is lost, one of the parties must reestablish it.

This can be a problem for fault-tolerant servers that require automatic switch overs to a backup server if the primary server fails.

The backup server needs to reestablish all the outstanding sessions with clients. Datagrams also known as connectionless protocols or transmits and pray protocols provide a simple but unreliable form of exchange.

The more powerful datagram protocols such as NetBIOS provide broadcast capabilities.

NetBIOS allows you to send datagrams to a named entity, to a select group of entities (multicast), or to all entities on a network (broadcast).

Datagrams are unreliable in the sense that they are not acknowledged or tracked through a sequence number. Some stacks (ex: LAN Servers MailSlots) provide an acknowledged datagram service. Datagrams are very useful to have in discovery types of situations. These are situations where you discover things about your network environment by broadcasting queries and learning who is out there from the response.

Broadcast can be used to obtain bids for services or to advertise the avilability of new services. Broadcast datagrams provide the capability of creating electronic bazaars The alternative to broadcast is to use a network directory service. Datagrams are also very useful in situations where there is a need to send a quick message (or) important message. Ex: All the systems have to send the I am alive message periodically to the network manager.
o

The ordinary method may need 500 sessions for each computer in the network and not possible.

Instead the system can broadcast the datagram to the manager.

1.14.2 . TLI

In 1986, AT&T introduced the Transport Layer Interface that provides functionality similar to sockets but in a more network-independent fashion. Sockets and TLI are very similar from a programmers perspective. TLI is just cleaner version of the sockets. It should run on IPX/SPX (or) TCP/IP with very few modifications. The TLI API consists of 25 API calls. Later standardized as XTI, X/Open Transport Interface.

1.14.3. NetBIOS:

It is the premier protocol for LAN-based, program-to-program communications. Introduced by IBM and Sytek in 1984 for the IBM PC network. It is used as an interface to a variety of stacks including NetBEUI, TCP/IP, XNS, Vines, OSI and IPX/SPX.

The NetBIOS services are provided through a set of commands, specified in a structure called the Network Control Block (NCB)

It does not support the routing of messages to other networks.

1.14.4. Named Pipes:

Provide highly reliable, two-way communications between clients and a server. They provide a file-like programming API that abstracts a session-based two-way exchange of data.

Using named pipes, processes can exchange data as if they were writing to, or reading from, a sequential file.

These are suitable for implementing server programs that require many-to-one pipelines.

Important benefit of named pipes are part of the base interprocess communications service.

Named pipes interface is identical, whether the processes are running on an individual machine or distributed across the network.

Named pipes run on NetBIOS, IPX/SPX, and TCP/IP stacks. Named pipes are built-in networking features in Windows NT, Windows for Workgroups, Windows 95 and Warp Server.

Unix support for Named Pipes is provided by LAN Manager/X.

1.14.5. CPI-C/APPC:

Common Programming Interface for Communications (CPI-C) build on top of APPC and marks its complexities and irregularities.

Writing to the CPI-C API allows you to port your programs to all SNA platforms. The CPI-C API consists of about 40 calls; APPC consists of over 60 calls. Most of these calls deals with configuration and services. Advanced program-to-program communication is a protocol which computer programs can use to communicate over a network. APPC was developed as a component of IBMs Systems Network Architecture (SNA).

APPC is linked with the term LU6.2. LU6.2. (Logic Unit Version 6.2) is a device independent SNA Protocol. It was developed to allow computers in IBM environments to setup their own communications sessions, rather than rely on a hos computer to do so.

Contrary to TCP/IP, in which both communication partners always possess a clear role, the communication partners in APPC are equal, i.e., everyone can be both servers and clients equally.

With the wide success of TCP/IP, APPC has declined.

RPC, Messaging and Peer to Peer

Client/Server applications are split across address spaces, physical machines, networks and operating systems.

All NOSs offer peer-to-peer interfaces that let applications communicate using close to the wire send/receive semantics.

Most NOSs provide some form of RPC middleware that hides the wire. An alternative type of model message queueing or simple MOM incredibly helpful in situations when the tight synchronization is not needed between the clients and servers.

Communication Stacks RPC Application Messaging Named Pipes DCE NDR SUN XDR Peer-toPeer

Presentation Session

Peer-to-peer service API NetBIOS Sockets TLI CPI-C/APPC Common Transport Semantics Transport TCP/IP Network LLC NetBEUI IEEE802.2 NDIS (OR) ODI MAC IEEE 802.5 (Token Ring) Fiber Optic IEEE 802.3 (Ethernet) Coax SDLC ISDN Twisted Pair SPX/IPX LU6.2 /APPN

Physical

Each layer has a well-defined set of APIs and Protocols. With these mix-and-match can be done. Practically, an entire stack of from a single vendor. The lowest layer of the communication software belongs to the device drivers that provide an interface to several types of communication hardware adapters. Real products dont have any notion of architectural boundaries or reference models they just get a job done.

At the lower layers, they interface to the hardware using MAC protocols defined by IEEE.

The LLC provides a common interface to the MACs and a reliable link service for transmitting communication packets between two nodes.

The transport layer provides end-to-end delivery service.