Sunday, 22 September 2013

Networking And Communications - Network Data Exchange Methods

Kind of Computer Networks Groups

A workgroup is a type of peer-to-peer network. It is essentially the name for a Windows based peer-to-peer computer network. Computers in this kind of network can allow each other access to their files, printers, or Internet connection.  A peer-to-peer network can’t have a domain because it doesn’t have a dedicated server computer to act as a domain controller. Instead, computers in a peer-to-peer network are grouped in workgroups, which are simply groups of computers that can share resources with each other. Each computer in a workgroup keeps track of its own user accounts and security settings, so no single computer is in charge of the workgroup.
 
 
 
 
A domain, on the other hand, is a client/server network in which the security and resource management is centralized. This means that a singular administration has control over the domain and allows which users have access to which files. In a Windows network, a domain is a group of server computers that share a common user account database. A user at a client computer can log in to a domain to access shared resources for any server in the domain. Each domain must have at least one server computer designated as the domain controller, which is ultimately in charge of the domain.  Most domain networks share this work among at least two domain controllers, so that if one of the controllers stops working, the network can still function.

 

Active Directory

Active Directory (AD) is a directory service implemented by Microsoft for Windows domain networks. It is included in most Windows Server operating systems.

An AD domain controller authenticates and authorizes all users and computers in a Windows domain type network—assigning and enforcing security policies for all computers and installing or updating software. For example, when a user logs into a computer that is part of a Windows domain, Active Directory checks the submitted password and determines whether the user is a system administrator or normal user.[1]

Active Directory makes use of Lightweight Directory Access Protocol (LDAP) versions 2 and 3, Microsoft's version of Kerberos, and DNS









Client Server Communication












Inter-process communication



In computing, inter-process communication (IPC) is a set of methods for the exchange of data among multiple threads in one or more processes. Processes may be running on one or more computers connected by a network. IPC methods are divided into methods for message passing, synchronization, shared memory, and remote procedure calls (RPC). The method of IPC used may vary based on the bandwidth and latency of communication between the threads, and the type of data being communicated.
There are several reasons for providing an environment that allows process cooperation:

IPC may also be referred to as inter-thread communication and inter-application communication.







Implementations



 There are several APIs which may be used for IPC. A number of platform independent APIs include the following:

The following are platform or programming language specific APIs:

Examples of IPC Implementation

Remote procedure call


In computer science, 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. 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.

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


Sequence of events during a RPC


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


Other RPC analogues

RPC analogues found elsewhere:

  • Java's Java Remote Method Invocation (Java RMI) API provides similar functionality to standard Unix RPC methods.
  • Modula-3's network objects, which were the basis for Java's RMI[5]
  • XML-RPC is an RPC protocol that uses XML to encode its calls and HTTP as a transport mechanism.
  • JSON-RPC is an RPC protocol that uses JSON-encoded messages
  • JSON-WSP is an RPC protocol that uses JSON-encoded messages
  • SOAP is a successor of XML-RPC and also uses XML to encode its HTTP-based calls.
  • RPyC implements RPC mechanisms in Python, with support for asynchronous calls.
  • Spyne defines primitives for doing RPC in Python. It also contains implementations of some of the most popular protocols and transports.[6]
  • Pyro object-oriented form of RPC for Python.
  • ZeroC's Internet Communications Engine (Ice) distributed computing platform.
  • Etch framework for building network services.
  • Facebook's Thrift protocol and framework.
  • BERT-RPC is an RPC protocol in use by Github [7][8]
  • CORBA provides remote procedure invocation through an intermediate layer called the object request broker.
  • Distributed Ruby (DRb) allows Ruby programs to communicate with each other on the same machine or over a network. DRb uses remote method invocation (RMI) to pass commands and data between processes.
  • Action Message Format (AMF) allows Adobe Flex applications to communicate with back-ends or other applications that support AMF.
  • Libevent provides a framework for creating RPC servers and clients.[9]
  • Windows Communication Foundation is an application programming interface in the .NET framework for building connected, service-oriented applications.
  • Microsoft .NET Remoting offers RPC facilities for distributed systems implemented on the Windows platform. It has been superseded by WCF.
  • The deprecated Microsoft DCOM uses MSRPC which is based on DCE/RPC
  • The Open Software Foundation DCE/RPC Distributed Computing Environment (also implemented by Microsoft).
  • Google Protocol Buffers (protobufs) package includes an interface definition language used for its RPC protocols.[10]
  • Google Web Toolkit uses an asynchronous RPC to communicate the server service.[11]
  • Apache Avro provides RPC where client and server exchange schemas in the connection handshake and code generation is not required.
  • Spike-Engine provides cross platform RPC facilities for .NET framework, web and mobile architectures with auto-generated stubs.
  • Twitter Finagle is a network stack for the JVM that you can use to build asynchronous Remote Procedure Call (RPC) clients and servers in Java, Scala, or any JVM-hosted language.




Sockets and Socket-based Communication











.NET Remoting


NET Remoting is a Microsoft application programming interface (API) for interprocess communication released in 2002 with the 1.0 version of .NET Framework. It is one in a series of Microsoft technologies that began in 1990 with the first version of Object Linking and Embedding (OLE) for 16-bit Windows. Intermediate steps in the development of these technologies were Component Object Model (COM) released in 1993 and updated in 1995 as COM-95, Distributed Component Object Model (DCOM), released in 1997 (and renamed Active X), and COM+ with its Microsoft Transaction Server (MTS), released in 2000.[1] It is now superseded by Windows Communication Foundation (WCF), which is part of the .NET Framework 3.0.
 
Like its family members and similar technologies such as Common Object Request Broker Architecture (CORBA) and Java's remote method invocation (RMI), .NET Remoting is complex, yet its essence is straightforward. With the assistance of operating system and network agents, a client process sends a message to a server process and receives a reply.[2][3]

.NET Remoting allows an application to make an object (termed remotable object) available across remoting boundaries, which includes different appdomains, processes or even different computers connected by a network.[4] The .NET Remoting runtime hosts the listener for requests to the object in the appdomain of the server application. At the client end, any requests to the remotable object are proxied by the .NET Remoting runtime over Channel objects, that encapsulate the actual transport mode, including TCP streams, HTTP streams and named pipes. As a result, by instantiating proper Channel objects, a .NET Remoting application can be made to support different communication protocols without recompiling the application. The runtime itself manages the act of serialization and marshalling of objects across the client and server appdomains.[4]








Web service


A web service is a method of communication between two electronic devices over the World Wide Web. A web service is a software function provided at a network address over the web or the cloud; it is a service that is "always on" as in the concept of utility computing.



The W3C defines a "Web service" as:

[...] a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.[1]
The W3C also states:
We can identify two major classes of Web services:
  • REST-compliant Web services, in which the primary purpose of the service is to manipulate XML representations of Web resources using a uniform set of "stateless" operations; and
  • arbitrary Web services, in which the service may expose an arbitrary set of operations.[2]







A web API is a development in web services where emphasis has been moving to simpler representational state transfer (REST) based communications.[3] RESTful APIs do not require XML-based web service protocols (SOAP and WSDL) to support their light-weight interfaces.





Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)