Peer – to – Peer Communications

January 16, 2008 at 4:06 pm (Unit 1) (, )

  • 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.

a) 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
    • 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.

b) 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 programmer’s 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.

c) 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.

d) 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.

e) 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 IBM’s 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.

APPC

Permalink Leave a Comment

RPC, Messaging and Peer to Peer

January 15, 2008 at 3:27 am (Unit 1) (, , , , )

  • 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

Stack

Application

Messaging

RPC

Peer-to-Peer

 

Named Pipes

DCE

SUN

 

Presentation

 

NDR

XDR

 

 

Session

Peer-to-peer service API

 

NetBIOS Sockets TLI CPI-C/APPC

 

Transport

Common Transport Semantics

 

NetBEUI

TCP/IP

SPX/IPX

LU6.2 /APPN

 

Network

 

LLC

IEEE802.2

 

MAC

NDIS (OR) ODI

 

IEEE 802.5 (Token Ring)

IEEE 802.3 (Ethernet)

SDLC

ISDN

 

Physical

Fiber Optic

Coax

Twisted Pair

 
  • 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 don’t 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.

Permalink Leave a Comment

Inside the Building Blocks

January 15, 2008 at 2:57 am (Unit 1) ()

Inside View

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
    • 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.

Server to Server

Permalink Leave a Comment

Client/Server : A one size fits all model

January 13, 2008 at 6:43 pm (Unit 1) ()

The building blocks of client/server applications are:

  1. Client
  2. Middleware
  3. Server

Building Blocks

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) 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.

Tiny Shop

2) 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 server’s name.
  • Security is implemented at the machine level and kept quite simple.
  • The network is usually relatively easy to administer; it’s a part-time job for a member of the group.
  • There are no complex interactions between servers, so it is easy to identify failures- they’re either on the client or on the local server.

small shop

3) 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 application’s 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
    • 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.

Intergalactic

4) 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.

Post Scarcity Model

Permalink Leave a Comment

Intergalactic Client/Server

January 13, 2008 at 5:38 pm (Unit 1) ()

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

Intergalactic Era client/server

Ethernet Era client/server

Number of clients per application

Millions

Less than 100

Number of servers per application

100,000+

<5

Geography

Global

Campus-based

Server-to-server Interactions

Yes

No

Middleware

ORBs on top of Internet

SQL and stored procedure

Client/server architecture

3-tier (or n-tier)

2-tier

Transactional updates

Pervasive

Very infrequent

Multimedia content

High

Low

Mobile Agents

Yes

No

Client front-ends

OOUIs, compound documents, and shippable places

GUI

Time-frame

1997 onwards

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.

Permalink Leave a Comment

2-Tier Vs 3-Tier

January 13, 2008 at 5:15 am (Unit 1) ()

  • 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.

Different Meanings for 3-tier:

First:

tier 1 – Application in PC

tier 2 – Departmental Servers

tier 3 – Enterprise Servers

Then:

tier 1 – Partitions across client

tier 2 – local database

tier 3 – enterprise database

Now:

tier 1 – Client

tier 2 – Application Server

tier 3 – Database Server

Permalink Leave a Comment

What is Middleware?

January 13, 2008 at 4:28 am (Unit 1) ()

  • Middleware does not include the software that provides the actual service that’s in the server’s domain.
  • It also does not include the user interface or the application’s logic that’s in the client’s 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

(a) 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.

(b) Service-Specific Middleware

  • It is need to accomplish a particular client/server type of service.
  • This includes
    • Database-specific middleware such as ODBC, DRDA, EDA/SQL, SAG/CLI and Oracle Glue.
    • OLTP-specific middleware such as Tuxedo’s ATMI and /WS, Encina’s Transactional RPC, and X/Open’s TxRPC and XATMI
    • Groupware-specific middleware such as MAPI, VIM, VIC, SMTP and Lotus Notes Calls
    • Object-specific middleware such as OMG’s CORBA and Microsoft’s Network OLE (or DCOM)
    • Internet-specific middleware such as HTTP, S-HTTP and SSL
    • System Management-specific middleware such as SNMP, CMIP and ORBs.

Permalink Leave a Comment