the fifth layer of the Open System Interconnection (OSI) model commonly called layer 5 in computer networking defines

es how to start, control and end conversations (called sessions) between applications. controls the connections between multiple computers. keep tracks the dialogs between computers, which are also called sessions.

 It is responsible for managing the communication connections between end devices. synchronizes dialogue between two hosts' presentation layers and manages their data exchange. acts as a liaison for the Presentation Layer by issuing service requests to Transport Layer. allow processes to communicate over the network, performing security, name recognition, logging, and so on.

 When the Session Layer is signaled by the Presentation Layer, it determines which port to establish the connection on, whether the data transfer will be half duplex or full duplex and what protocols will be used during the connection. Once the communication is complete or has been idle for a set amount of time, Session Layer terminates the session.

Session layer protocols are particularly useful for multimedia applications for which it is necessary to coordinate the timing of two or more types of data, such as voice and moving images, with a high degree of precision. The session layer of the OSI model is responsible for session checkpointing and recovery. It allows information of different streams, perhaps originating from different sources, to be properly combined or synchronized.

Example: Application in Web Conferencing Application in live TV programs

Common protocols that are used by the Session Layer:

ADSP, AppleTalk Data Stream Protocol ASP, AppleTalk Session Protocol H.245, Call Control Protocol for Multimedia Communication ISO-SP, OSI session-layer protocol (X.225, ISO 8327) iSNS, Internet Storage Name Service L2F, Layer 2 Forwarding Protocol L2TP, Layer 2 Tunneling Protocol NetBIOS, Network Basic Input Output System PAP, Password Authentication Protocol PPTP, Point-to-Point Tunneling Protocol RPC, Remote Procedure Call Protocol RTCP, Real-time Transport Control Protocol SMPP, Short Message Peer-to-Peer SCP, Session Control Protocol SOCKS, the SOCKS internet protocol ZIP, Zone Information Protocol SDP, Sockets Direct Protocol

Authentications - It verifies the information for the application. If the verification/password is correct, the Session Layer will allow it to pass. If the verification/password data is incorrect, the session is terminated and no connection is established or dropped Permissions - In this layer, function is much the same as authentication does. Verification that a host has the right credentials to perform certain tasks within application takes place here. Session Restoration - the Session Layer is fault tolerant. During a session, data may not be passes for a preset amount of time, but it has not received the end transmission request. The Session Layer will close the session and reopen it and will refresh the session.

AppleTalk Data Stream Protocol (ADSP)

 it was released for the original Macintosh in 1985 and was the primary protocol used by Apple devices through the 1980s and 90s. a proprietary suite of networking protocols developed by Apple Inc. for their Macintosh computers. included a number of features that allowed local area networks to be connected with no prior setup or the need for a centralized router or server of any sort. a protocol which provides a simple transport method for data across a network. sometimes called a connection-oriented protocol. manages and controls the data ow between the two sockets throughout the session to ensure that the data is delivered and received in the order in which it was sent.

 includes both session and transport services, and it is the most commonly used of the port protocols. builds a session connection on top of the packet transfer services that DDP provides so that applications using ADSP can exchange data as a continuous stream. assigns a socket to be used when you initialize each end of the connection, and your application becomes a client of that socket. Because this connection exists for the duration of the exchange. application or process at the receiving end of the connection has the buffer capacity to accept the data.

 a connection attempt could be rejected there were no "half-open" connections; once one end initiated a tear-down of the connection, the whole connection would be closed (note: ADSP is full-duplex, not dual simplex).

AppleTalk Session Protocol

 provides an application programming interface for the workstation side only. is not commonly used by application program developers. primary use is to provide services for the AppleTalk Filing Protocol (AFP) that, in turn, provides all of the services necessary to access an AppleTalk AppleShare server. most developers who want to write an AppleTalk application that establishes a session use the AppleTalk Data Stream Protocol (ADSP) because it provides peer-to-peer services.

Apple Filing Protocol

formerly AppleTalk Filing Protocol, is the protocol for communicating with AppleShare file servers. built on top of AppleTalk Session Protocol (for legacy AFP over DDP) or the Data Stream Interface (for AFP over TCP). it provides services for authenticating users (extensible to different authentication methods including two-way random-number exchange) and for performing operations specific to the Macintosh HFS file system. is still in use in Mac OS X, even though most other AppleTalk protocols have been deprecated.

 was an intermediate protocol, built on top of ATP, which in turn was the foundation of AFP. it provided basic services for requesting responses to arbitrary commands and performing out-of-band status queries. it also allowed the server to send asynchronous attention messages to the client.

AppleTalk Transaction Protocol

was the original reliable transport-level protocol for AppleTalk, built on top of DDP. At the time it was being developed, a full, reliable connectionoriented protocol like TCP was considered to be too expensive to implement for most of the intended uses of AppleTalk. was a simple request/response exchange, with no need to set up or tear down connections.

Datagram Delivery Protocol

was the lowest-level data-link-independent transport protocol.

it provided a datagram service with no guarantees of delivery. All application-level protocols, including the infrastructure protocols NBP, RTMP and ZIP, were built on top of DDP.

Name Binding Protocol

was a dynamic, distributed system for managing AppleTalk names. provided a system for checking that no other machine had already registered the same name. Later, when a client wanted to access that service, it used NBP to query machines to find that service.

AppleTalk Echo Protocol

is a transport layer protocol designed to test the reachability of network nodes. generates packets to be sent to the network node and is identified in the Type field of a packet as an AEP packet. packet is first passed to the source DDP.

Printer Access Protocol

was the standard way of communicating with PostScript printers. it was built on top of ATP. When a PAP connection was opened, each end sent the other an ATP request which basically meant "send me more data". The client's response to the server was to send a block of PostScript code, while the server could respond with any diagnostic messages that might be generated as a result, after which another "send-more-data" request was sent. provided automatic flow control; each end could only send data to the other end if there was an outstanding ATP request to respond to.

Routing Table Maintenance Protocol

was the protocol by which routers kept each other informed about the topology of the network. the only part of AppleTalk that required periodic unsolicited broadcasts: every 10 seconds, each router had to send out a list of all the network numbers it knew about and how far away it thought they were.

Zone Information Protocol (ZIP)

 was the protocol by which AppleTalk network numbers were associated with zone names. A zone was a subdivision of the network that made sense to humans but while a network number had to be assigned to a topologicallycontiguous section of the network, a zone could include several different discontiguous portions of the network.

 provides applications and processes with access to zone names. a zone is a logical grouping of nodes in an AppleTalk internet, and each zone is identied by a name. a zone name is typically used to identify an affiliation between a group of nodes, such as a group of nodes belonging to a particular department within an organization. builds a zone information table that includes each networks number (extended networks have network number ranges) in association with the networks list of zones.

ZIP maintains the mapping of networks and the zones they include for all networks belonging to an AppleTalk internet: every node on a network belongs to a zone; a node can belong to only one zone at a time. a non-extended network contains only one zone, and all nodes in that network belong to the same zone. a single extended network can contain nodes that belong to up to 255 different zones.

Call Control Protocol for Multimedia Communication (H.245)

 is a control channel protocol used within H.323 and H.324 communication sessions, and involves the line transmission of non-telephone signals. it also offers the possibility to be tunneled within H.225.0 call signaling messages. capable of conveying information needed for multimedia communication, such as encryption, flow control, jitter management, preference requests, as well as the opening and closing of logical channels used to carry media streams. it also defines separate send and receive capabilities and the means to send these details to other devices that support H.323.

Network Basic Input/output System (NETBIOS)

 introduced in 1983 by IBM as an improvement to the standard BIOS used by Windows-based computers a program that allows applications on different computers to communicate within a local area network (LAN) provides services related to the session layer of the OSI model allowing applications on separate computers to communicate over a local area network is an application programming interface (API), not a networking protocol was created by IBM for its early PC Network and was adopted by Microsoft is used in Ethernet and Token Ring networks

 does not support a routing mechanism on a wide area network (WAN) frees the application from having to understand the details of the network, including error recovery (in session mode) specifies a message location and the name of a destination provides the session and transport services described in the Open Systems Interconnection (OSI) model it does not provide a standard frame or data format for transmission prevents programmers from having to "reinvent the wheel" just to get their program to connect to a network included as part of NetBIOS Extended User Interface (NetBEUI), in recent Microsoft Windows operating systems

NetBIOS provides three distinct services:

1. Name service (NetBIOS-NS) - for name registration and resolution
The name service primitives offered by NetBIOS are:
Add name registers a NetBIOS name Add group name registers a NetBIOS "group" name Delete name un-registers a NetBIOS name or group name Find name looks up a NetBIOS name on the network

2. Datagram distribution service (NetBIOS-DGM)

- for connectionless communication

The datagram service primitives offered by NetBIOS are:

Send Datagram send a datagram to a remote NetBIOS name. Send Broadcast Datagram send a datagram to all NetBIOS names on the network. Receive Datagram wait for a packet to arrive from a Send Datagram operation. Receive Broadcast Datagram wait for a packet to arrive from a Send Broadcast Datagram operation.

3. Session service (NetBIOS-SSN) -for connection-oriented communication The session service primitives offered by NetBIOS are:
Call opens a session to a remote NetBIOS name. Listen listen for attempts to open a session to a NetBIOS name. Hang Up close a session. Send sends a packet to the computer on the other end of a session. Send No Ack like Send, but doesn't require an acknowledgment. Receive wait for a packet to arrive from a Send on the other end of a session.

TWO COMMUNICATION MODES

Session mode - lets two computers establish a connection for a "conversation - allows larger messages to be handled - provides error detection and recovery Datagram - is "connectionless" (each message is sent independently) - messages must be smaller - the application is responsible for error detection and recovery - also supports the broadcast of a message to every computer on the LAN

NETBIOS NAME
16 ASCII characters usually an IP address often the same as that computer's host name although truncated to 15 characters a sequence of alphanumeric characters hyphen ("-") and full-stop (".") characters may also be used in the NetBIOS name, but not as the first or last character

NetBIOS Suffixes
For unique names: 00: Workstation Service (workstation name) 03: Windows Messenger service 06: Remote Access Service 20: File Service (also called Host Record) 21: Remote Access Service client 1B: Domain Master Browser Primary Domain Controller for a domain 1D: Master Browser For group names: 00: Workstation Service (workgroup/domain name) 1C:Domain Controllers for a domain (group record with up to 25 IP addresses) 1E: Browser Service Elections

Password Authentication Protocol (PAP)

 an authentication protocol that uses a password a protocol where two entities share a password in advance and use the password as the basis of authentication used by Point to Point Protocol to validate users before allowing them access to server resources transmits unencrypted ASCII passwords over the network and is therefore considered insecure

 validate the identity of the originator of the connection passwords are sent over the circuit "in the clear" a nd there is no protection against playback or repeated "trial an d error" attacks principle of the PAP is to send the username and password in clear text across the network

WORKING CYCLE Client sends username and password Server sends authentication-acknowledgement (if credentials are OK) or authentication-not acknowledgement (otherwise) AUTHENTICATION SCHEMES 1. Weak-Password Authentication Schemes tend to have lighter computational overhead the designs are simpler implementation is easier 2. Strong-Password Authentication Schemes more secure compare to Weak-Password Authentication Schemes has higher entropy

Session Control Protocol (SCP)

 also known as X.225 or ISO 8327 a protocol specification recommended by the International Telecommunication Union (ITU) this protocol may try to recover the connection (In case of a connection loss) this protocol may close a connection if is not used for a long period and re-open it provides for either full duplex or half-duplex operation provides synchronization points in the stream of exchanged messages provide services for coordinating communication between local and remote applications (establishing, managing and terminating connections)

ISO-SP, OSI SessionLayer Protocol X.225 (ISO 8327)

 is a connection-oriented session layer protocol in the Open Systems Interconnection (OSI) model. The ITU X.225 protocol specification is a recommendation of the International Telecommunication Union (ITU).

ITU X.225 and other session layer protocol use:

suspend/resume

checkpoint/rollback capabilities
for synchronization of audio and video

Internet Storage Name Service (iSNS)

 provides management services similar to those found in Fibre Channel networks, allowing a standard IP network to operate in much the same way that a Fibre Channel storage area network does. Because iSNS is able to emulate Fibre Channel fabric services and manage both iSCSI and Fibre Channel devices, an iSNS server can be used as a consolidated configuration point for an entire storage network. However, standards-compliant iSNS implementations are required to support the iFCP protocol, supporting the iSCSI protocol is optional.

The iSNS standard defines four components:

iSNS Protocol iSNS Clients iSNS Servers iSNS Databases

iSNS Protocol
iSNSP is a protocol that specifies how iSNS clients and servers communicate. It is intended to be used by various platforms, including switches and targets as well as server hosts.

iSNS Clients
iSNS clients are part of iSNSP aware storage devices. iSNS clients initiate transactions with iSNS servers using the iSNSP. register device attribute information in a common Discovery Domain (DD) download information about other registered clients receive asynchronous notification of events that occur in their DD(s).

iSNS Servers
iSNS servers respond to iSNS protocol queries and requests made by iSNS clients using the iSNSP. iSNS servers initiate iSNSP State Change Notifications and store properly authenticated information submitted by a registration request in an iSNS database.

iSNS Databases
iSNS databases are the information repositories for iSNS server(s). They maintain information about iSNS client attributes; while implementations will vary, a directory-enabled implementation of iSNS, for example, might store client attributes in an LDAP directory.

Services
An iSNS implementation provides four primary services: Name Registration and Storage Resource Discovery Discovery Domains and Login Control State Change Notification Bidirectional Mappings Between Fibre Channel and iSCSI Devices

Name Registration and Storage Resource Discovery

iSNS implementations allow all entities in a storage network to register and query an iSNS database. Both targets and initiators can register with the iSNS database, and each entity can inquire about other initiators and targets. For example, a client initiator can obtain information about target devices from an iSNS server.

Discovery Domains and Login Control

Administrators can use the Discovery Domains to divide storage nodes into manageable, non-exclusive groups. By grouping storage nodes, administrators are able to limit the login process of each host to the most appropriate subset of targets registered with the iSNS, which allows the storage network to scale by reducing the number of unnecessary logins and by limiting the amount of time each host spends establishing login relationships.

State Change Notification

The State Change Notification (SCN) service allows an iSNS Server to issue notifications about each event that affects storage nodes on the managed network. Each iSNS client may register for notifications on behalf of its storage nodes, and each client is expected to respond according to its own requirements and implementation.

Bidirectional mappings between fibre channel and iSCSI device

Because the iSNS database stores naming and discovery information about both Fibre Channel and iSCSI devices, iSNS servers are able to store mappings of Fibre Channel devices to proxy iSCSI device images on the IP network. These mappings may also be made in the opposite direction, allowing iSNS servers to store mappings from iSCSI devices to proxy WWNs.

Layer 2 Forwarding Protocol

 A media-independent tunnelling protocol developed by Cisco Systems. The Layer 2 Forwarding (L2F) protocol tunnels data-link layer frames in such protocols as Point-to-Point Protocol (PPP) or Serial Line Internet Protocol (SLIP), making it possible to create virtual private networks (VPNs) over a public network such as the Internet. On the server side, L2F can be used with such features as user authentication through Remote Authentication Dial-In User Service (RADIUS), dynamic allocation of addresses, and quality of service (QoS). L2F is implemented in Cisco routers through Ciscos Internetwork Operating System (IOS).

How It Works 1.When using PPP with L2F, for example, PPP provides the connection between a dial-up client and the network access server (NAS) that receives the call. 2. A PPP connection initiated by a client terminates at a NAS located at a PPP service provider, usually an Internet service provider (ISP). 3. L2F allows the termination point of the connection to be extended beyond the NAS to a remote destination node, so the clients connection appears to be directly to the remote node instead of to the NAS.

4. The function of the NAS in L2F is simply to project or forward PPP frames from the client to the remote node. This remote node is called a home gateway in Cisco networking terminology.

NOTE :
L2F has been largely superseded by the newer Layer 2 Tunneling Protocol (L2TP), an Internet Engineering Task Force (IETF) standard protocol that provides a vendor-neutral tunneling solution. L2TP is an extension of the PPP protocol that supports the best features of the Point-to-Point Tunneling Protocol (PPTP) and the L2F protocol.

L2TP is one of the key building blocks for virtual private networks in the dial access space and is endorsed by Cisco and other internetworking industry leaders.

Layer Two Tunneling Protocol (L2TP) is an extension of the Point-to-Point Tunneling Protocol (PPTP) used by an Internet service provider (ISP) to enable the operation of a virtual private network (VPN) over the Internet.
L2TP merges the best features of two other tunneling protocols: PPTP Point-to-Point Tunneling Protocol from Microsoft and L2F Layer 2 Forwarding Protocol from Cisco Systems.

 Published in 1999 as proposed standard RFC 2661, L2TP has its origins primarily in two older tunneling protocols for Point-to-Point communication: Cisco's Layer 2 Forwarding Protocol (L2F) and USRobotics Pointto-Point Tunneling Protocol (PPTP). A new version of this protocol, L2TPv3, was published as proposed standard RFC 3931 in 2005.

L2TPv3 provides additional security features, improved encapsulation, and the ability to carry data links other than simply PPP (PPP) over an IP network (e.g., Frame Relay, Ethernet, ATM, etc.).

1. L2TP Access Concentrator (LAC) is the initiator of the tunnel which is the device that physically terminates a call 2. L2TP Network Server (LNS) is the server, which waits for new tunnels which is the device that terminates and possibly authenticates the PPP stream.

 Control messages Used in L2TP tunnel and session setup, maintenance, and teardown. Control messages are reliably transmitted inband over a control connection between the LAC and the LNS. Only one control connection is required for each L2TP tunnel regardless of the number of data sessions. Data messages Used to transport PPP frames between the LAC and the LNS. Each PPP connection is carried over a separate data session within the L2TP tunnel.

The end device, often a user PC or laptop, establishes a PPP connection to a server known as the LAC (L2TP Access Concentrator) using dialup POTS, DSL, and so on. The LAC then initiates an L2TP tunneling session, using normal IP, to the remote device with which the originating device wants to set up a session. This remote device is called the LNS (L2TP Network Server). Typically the authentication, authorization, and accounting (AAA) of the end user is done on the LNS itself using a local database or AAA server.

The LAC is the initiator of the tunnel while the LNS is the server, which waits for new tunnels. Once a tunnel is established, the network traffic between the peers is bidirectional. To be useful for networking, higher-level protocols are then run through the L2TP tunnel. To facilitate this, an L2TP session (or 'call') is established within the tunnel for each higher-level protocol such as PPP. Either the LAC or LNS may initiate sessions. The traffic for each session is isolated by L2TP, so it is possible to set up multiple virtual networks across a single tunnel.

Voluntary L2TP Tunneling The client is aware of the presence of an L2TP connection. The LAC is unaware of L2TP. (client) PPP + L2TP + Data (LAC) L2TP + Data (LNS)

Compulsory L2TP Tunneling The client is completely unaware of the presence of an L2TP connection. The L2TP Access Concentrator (LAC) is aware of L2TP. (client) PPP + Data (LAC) L2TP + Data (LNS)

Field meanings: Flags and version control flags indicating data/control packet and presence of length, sequence, and offset fields. Length (optional) Total length of the message in bytes, present only when length flag is set. Tunnel ID Indicates the identifier for the control connection. Session ID Indicates the identifier for a session within a tunnel. Ns (optional) sequence number for this data or control message, beginning at zero and incrementing by one for each message sent. Present only when sequence flag set. Nr (optional) sequence number for expected message to be received. Nr is set to the Ns of the last in-order message received plus one In data messages, Nr is reserved and, if present (as indicated by the S bit), MUST be ignored upon receipt.. Offset Size (optional) Specifies where payload data is located past the L2TP header. If the offset field is present, the L2TP header ends after the last byte of the offset padding. This field exists if the offset flag is set. Offset Pad (optional) Variable length, as specified by the offset size. Contents of this field are undefined. Payload data Variable length (Max payload size = Max size of UDP packet size of L2TP header)

An L2TP packet consists of : Bits 015 Bits 1631 Flags and Version Info Length (opt) Tunnel ID Session ID Ns (opt) Nr (opt) Offset Size (opt) Offset Pad (opt)...... Payload data

The Point-to-Point Tunneling Protocol (PPTP) is a method for implementing virtual private networks. PPTP is considered cryptographically broken and its use is no longer recommended by Microsoft. The PPTP specification does not describe encryption or authentication features and relies on the Point-toPoint Protocol being tunneled to implement security functionality. However, the most common PPTP implementation shipping with the Microsoft Windows product families implements various levels of authentication and encryption natively as standard features of the Windows PPTP stack.

The intended use of this protocol is to provide security levels and remote access levels comparable with typical VPN products. PPTP uses a control channel over TCP and a GRE tunnel operating to encapsulate PPP packets.

 A specification for PPTP was published in July 1999 as RFC 2637 and was developed by a vendor consortium formed by Microsoft, Ascend Communications (today part of AlcatelLucent), 3Com, and others. PPTP has not been proposed nor ratified as a standard by the IETF. A PPTP tunnel is instantiated by communication to the peer on TCP port 1723. This TCP connection is then used to initiate and manage a second GRE tunnel to the same peer. The PPTP GRE packet format is non standard, including an additional acknowledgement field replacing the typical routing field in the GRE header. However, as in a normal GRE connection, those modified GRE packets are directly encapsulated into IP packets, and seen as IP protocol number 47. In the Microsoft implementation, the tunneled PPP traffic can be authenticated with PAP, CHAP, MS-CHAP v1/v2 or EAP-TLS. The PPP payload is encrypted using Microsoft Point-to-Point Encryption (MPPE) when using MS-CHAPv1/v2 or EAP-TLS. MPPE is described by RFC 3078.

PPTP was the first VPN protocol that was supported by Microsoft Dialup Networking. All releases of Microsoft Windows since Windows 95 OSR2 are bundled with a PPTP client, although they are limited to only 2 concurrent outbound connections. Microsoft Windows Mobile 2003 and higher also support the PPTP protocol. The Routing and Remote Access Service for Microsoft Windows contains a PPTP server. The Microsoft implementation uses single DES in the MS-CHAP authentication protocol which many find unsuitable for data protection needs. Windows Vista and later support the use of PEAP with PPTP. The authentication mechanisms supported are PEAPv0/EAP-MSCHAPv2 (passwords) and PEAP-TLS (smartcards and certificates). Windows Vista removed support for using the MSCHAP-v1 protocol to authenticate remote access connections.

Linux server-side support for PPTP is provided by the PoPToP daemon and kernel modules for PPP and MPPE. Client-side Linux implementations of PPTP appeared in 1997,[5] but the first widely used server-side Linux PPTP implementation was developed by Matthew Ramsay in 1999[6] and initially distributed under the GNU GPL by Moreton Bay. However, Linux distributions initially lacked full PPTP support because MPPE was believed to be patent encumbered. Full MPPE support was added to the Linux kernel in the 2.6.14 release on October 28, 2005. SuSE Linux 10 was the first Linux distribution to provide a complete working PPTP client. There is also ACCEL-PPP PPTP/L2TP/PPPoE server for Linux[7] which supports PPTP in kernelmode. OS X and iOS are bundled with a PPTP client. Cisco and Efficient Networks sell PPTP clients for older Mac OS releases. Palm PDA devices with Wi-Fi are bundled with the Mergic PPTP client.[citation needed] Many different Mobile phones with Android as the operating system support PPTP as well.

 PPTP is (as of October 2012) considered cryptographically broken and its use is no longer recommended by Microsoft[citation needed]. A summary of these vulnerabilities is below: MSCHAP-v1 is fundamentally insecure. Tools exist to trivially extract the NT Password hashes from a captured MSCHAP-v1 exchange. When using MSCHAP-v1, MPPE uses the same RC4 session key for encryption in both directions of the communication flow. This can be cryptanalysed with standard methods by XORing the streams from each direction together. MSCHAP-v2 is vulnerable to dictionary attack on the captured challenge response packets. Tools exist to perform this process rapidly.

 In 2012, it was shown that brute-force attack on MSCHAP-v2 is equivalent to single DES key brute-force attack. Online service was presented, which is capable to restore MSCHAP-v2 passphrase's MD4 in 23 hours. MPPE uses RC4 stream cipher for encryption. There is no method for authentication of the ciphertext stream and therefore the ciphertext is vulnerable to a bit-flipping attack. An attacker could modify the stream in transit and adjust single bits to change the output stream without possibility of detection. These bit flips may be detected by the protocols themselves through checksums or other means. EAP-TLS is seen as the superior authentication choice for PPTP;however, it requires implementation of a Public Key Infrastructure for both client and server certificates. As such it is not a viable authentication option for many remote access installations.

That is, the programmer writes essentially the same code whether the subroutine is local to the executing program, or remote. When the software in question uses object- oriented principles, RPC is called remote invocation or remote method invocation.

a remote procedure call (RPC) is an inter-process communication that allows a computer program to cause a subroutine or procedure to execute in another address space(commonly on another computer on a shared network) without the programmer explicitly coding the details for this remote interaction.

Many different (often incompatible) technologies have been used to implement the concept.

 The idea of treating network operations as remote procedure calls goes back at least to the 1980s in early ARPANET documents. -- Bruce Jay Nelson is generally credited with coining the term. One of the first business uses of RPC was by Xerox under the name "Courier" in 1981. The first popular implementation of RPC on Unix was Sun's RPC (now called ONC RPC), used as the basis for Network File System.

 An RPC is initiated by the client, which sends a request message to a known remote server to execute a specified procedure with supplied parameters. he remote server sends a response to the client, and the application continues its process. While the server is processing the call, the client is blocked (it waits until the server has finished processing before resuming execution), unless the client sends an asynchronous request to the server, such as an XHTTP call. There are many variations and subtleties in various implementations, resulting in a variety of different (incompatible) RPC protocols. An important difference between remote procedure calls and local calls is that remote calls can fail because of unpredictable network problems. Also, callers generally must deal with such failures without knowing whether the remote procedure was actually invoked. Idempotent procedures (those that have no additional effects if called more than once) are easily handled, but enough difficulties remain that code to call remote procedures is often confined to carefully written lowlevel subsystems.

o The client calls the client stub. The call is a local procedure call, with parameters pushed on to the stack in the normal way. o The client stub packs the parameters into a message and makes a system call to send the message. Packing the parameters is called marshalling. o The client's local operating system sends the message from the client machine to the server machine. o The local operating system on the server machine passes the incoming packets to the server stub. o The server stub unpacks the parameters from the message. Unpacking the parameters is called unmarshalling. o Finally, the server stub calls the server procedure. The reply traces the same steps in the reverse direction.

To let different clients access servers, a number of standardized RPC systems have been created. Most of these use an interface description language (IDL) to let various platforms call the RPC. The IDL files can then be used to generate code to interface between the client and server. The most common tool used for this is RPCGEN
RPCGEN is an interface generator precompiler for Sun Microsystems ONC RPC. It uses an interface definition file to create client and server stubs in C. RPCGEN creates stubs based on information contained within an IDL file.

The Sockets Direct Protocol (SDP) is a networking protocol originally defined by the Software Working Group (SWG) of the InfiniBand Trade Association. Originally designed for InfiniBand (IB), SDP now has been redefined as a transport-agnostic protocol for Remote Direct Memory Access (RDMA) network fabrics. SDP defines a standard wire protocol over an RDMA fabric to support stream sockets (SOCK_STREAM). SDP uses various RDMA network features for high-performance zero-copy data transfers. SDP is a pure wire-protocol level specification and does not go into any socket API or implementation specifics.

The purpose of the Sockets Direct Protocol is to provide an RDMA-accelerated alternative to the TCP protocol on IP. The goal is to do this in a manner which is transparent to the application. Oracle Solaris 10 and Oracle Solaris 11 Express also include support for SDP. Several other Unix operating system variants plan to include support for Sockets Direct Protocol. Microsoft Windows offers a subsystem called Winsock Direct, which could be used to support SDP. SDP support was introduced to the JDK 7 release of the Java Platform, Standard Edition (July 2011) for applications deployed in the Solaris operating system and on Linux operating systems (OFED 1.4.2 and 1.5). Oracle Database 11g supports connection over SDP.

Sockets Direct Protocol only deals with stream sockets, and if installed in a system, bypasses the OS resident TCP stack for stream connections between any endpoints on the RDMA fabric. All other socket types (such as datagram, raw, packet, etc.) are supported by the Linux IP stack and operate over standard IP interfaces (i.e., IPoIB on InfiniBand fabrics). The IP stack has no dependency on the SDP stack; however, the SDP stack depends on IP drivers for local IP assignments and for IP address resolution for endpoint identifications.

SDP is used by the Australian telecommunications company Telstra on their 3G platform Next G to deliver streaming mobile TV.

Real-time Transport Control Protocol (RTCP)

 Sister protocol of the Real-time Transport Protocol(RTP) provides out-of-band statistics and control information for an RTP flow. gathers statistics for a media connection and information such as transmitted octet and packet counts, lost packet counts, jitter, and round-trip delay time. does not provide any flow encryption or authentication methods.

Protocol Function
The primary function of RTCP is to gather statistics on quality aspects of the media distribution during a session and transmit this data to the session media source and other session participants. RTCP provides canonical end-point identifiers (CNAME) to all session participants. RTCP reports are expected to be sent by all participants, even in a multicast session which may involve thousands of recipients. The provisioning of session control functions, because RTCP is a convenient means to reach all session participants, whereas RTP itself is not. RTP is only transmitted by a media source.

Message/Packets Types
Sender report (SR)

- The sender report is sent periodically by the active senders in a conference to report transmission and reception statistics for all RTP packets sent during the interval.
Receiver report (RR)

- It is for passive participants, those that do not send RTP packets. The report informs the sender and other receivers about the quality of service.
Source description (SDES) - is used to send the CNAME item to session participants. End of participation (BYE)

- A source sends a BYE message to shut down a stream.

Application-specific message (APP)

- Provides a mechanism to design application-specific extensions to the RTCP protocol.

Scalability in large deployments

Very long delays (minutes to hours) between RTCP reports may occur, because of the RTCP bandwidth control mechanism required to control congestion.

Hierarchical aggregation Hierarchical aggregation RTCP feedback hierarchy is an optimization of the RTCP feedback model and its aim is to shift the maximum number of users limit further together with QoS measurement.

Short Message Peer-to-Peer (SMPP)

 Designed by Aldiscon, Irish company that was acquired by Logica. Created by Ian J. Chambers The SMPP is an open, industry standard protocol designed to provide a flexible data communication interface for the transfer of short message data between External Short Messaging Entities (ESME), Routing Entities (RE) and Message Centres. Because of its support for non-GSM SMS protocols, like UMTS, IS-95 (CDMA), CDMA2000, ANSI136 (TDMA) and iDEN, the SMPP is the most commonly used protocol for short message exchange outside SS7 networks.

SMPP Versions
SMPP 3.3 SMPP 3.4 SMPP 5.0

SOCKS Internet Protocol

an Internet protocol that routes network packets between a client and server through a proxy server. SOCKS additionally provides authentication so only authorized users may access a server.

Usage
De facto standard for circuit-level gateways Circumvention tool SSH suites, support dynamic port forwarding that allows the user to create a local SOCKS proxy. Can be use in Tor onion proxy software

Comparison to HTTP proxying SOCKS operates at a lower level than HTTP proxying: SOCKS uses a handshake protocol to inform the proxy software about the connection that the client is trying to make, and then acts as transparently as possible, whereas an HTTP proxy may interpret and rewrite headers. SOCKS proxies can also forward UDP traffic and work in reverse, while HTTP proxies cannot.

PRESENTED BY: ACLAN, MELVIN Z. CASTOR, CLENT CYRUS T. CERILLO, JENNY ROSE V. JUROGUAS, MARVIN R. MARASIGAN, VENUS C. ODICPA, JOSEPH MARK E.