The ​Internet Control Message Protocol​ (​ICMP​) is one of the core protocols of the ​Internet

Protocol Suite​. It is chiefly used by the ​operating systems​ of networked computers to send error
messages—indicating, for instance, that a requested service is not available or that a host or
router could not be reached.
ICMP​[1]​ relies on ​IP​ to perform its tasks, and it is an integral part of ​IP​. It differs in purpose from
transport protocols such as ​TCP​ and ​UDP​ in that it is typically not used to send and receive data
between end systems. It is usually not used directly by user network applications, with some
notable exceptions being the ​ping​ tool and ​traceroute​.
ICMP for ​Internet Protocol version 4​ (IPv4) is also known as ICMPv4. ​IPv6​ has a similar
protocol, ​ICMPv6​.

Technical details
Internet Control Message Protocol is part of the ​Internet Protocol Suite​ as defined in ​RFC 792​.
ICMP messages are typically generated in response to errors in ​IP​ ​datagrams​ (as specified in
RFC 1122​) or for diagnostic or routing purposes.
ICMP messages are constructed at the IP layer, usually from a normal IP datagram that has
generated an ICMP response. IP encapsulates the appropriate ICMP message with a new IP
header​ (to get the ICMP message back to the original sending host) and transmits the resulting
datagram in the usual manner.
For example, every machine (such as an intermediate ​router​) that forwards an IP datagram has to
decrement the ​time to live​ (TTL) field of the IP header by one; if the TTL reaches 0, an ICMP
Time to live exceeded in transit​ message is sent to the source of the datagram.
Each ICMP message is encapsulated directly within a single IP datagram, and thus, like ​UDP​,
ICMP is ​unreliable​.
Although ICMP messages are contained within standard IP datagrams, ICMP messages are
usually processed as a special case, distinguished from normal IP processing, rather than
processed as a normal sub-protocol of IP. In many cases, it is necessary to inspect the contents of
the ICMP message and deliver the appropriate error message to the application that generated the
original IP packet, the one that prompted the sending of the ICMP message.
Many commonly-used network utilities are based on ICMP messages. The ​traceroute​ command
is implemented by transmitting UDP datagrams with specially set IP TTL header fields, and
looking for ICMP ​Time to live exceeded in transit​ (above) and "Destination unreachable"
messages generated in response. The related ​ping​ utility is implemented using the ICMP "Echo
request" and "Echo reply" messages.
ICMP segment structure
[Header
The ICMP header starts after the ​IPv4​ header.
Bits 0-7 8-15 16-23 24-31
0 Type Code Checksum
32 ID Sequence
·​ ​Type​ - ICMP type as specified below.
·​ ​ ode​ - further specification of the ICMP type; e.g. : an ICMP Destination
C
Unreachable might have this field set to 1 through 15 each bearing different meaning.
·​ ​Checksum​ - This field contains error checking data calculated from the ICMP
header+data, with value 0 for this field. The algorithm is the same as the header
checksum for ​IPv4​.
·​ ​ID​ - This field contains an ID value, should be returned in case of ECHO REPLY.
·​ ​Sequence​ - This field contains a sequence value, should be returned in case of
ECHO REPLY.
[​edit​] Padding data
Padding data follows the ICMP header (in ​octets​):
·​ The ​Linux​ "ping" utility pads ICMP to a total size of 56 bytes in addition to the 8
octet header.
·​ ​Windows​ "ping.exe" pads to a total size of 32 bytes in addition to the 8 octet
header.

General Inter-ORB Protocol

In ​distributed computing​, ​General Inter-ORB Protocol​ (​GIOP​) is the abstract ​protocol​ by
which ​object request brokers​ (ORBs) communicate. Standards associated with the protocol are
maintained by the ​Object Management Group​ (OMG).
IIOP​ (Internet Inter-Orb Protocol) is the implementation of GIOP for ​TCP/IP​. It is a concrete
realization of the abstract GIOP definitions.

Message types
The Object Management Group defines three parts of GIOP:
·​ ​ he ​Common Data Representation​ (CDR)​ - transfer syntax mapping OMG IDL
T
data types into a low-level representation for “on-the-wire” transfer between ORBs and
Inter-ORB bridges.
·​ ​ he ​Interoperable Object Reference​ (IOR)​ - define the format of a reference to a
T
remote object. An IOR consists of tagged profiles and their components that may carry
various needed information. The typical IOR usually contains the protocol version, server
address and a byte sequence identifying the remote object (object key).
·​ ​The defined message formats​ - messages are exchanged between agents to
facilitate object requests, locate object implementations, and manage communication
channels. Messages are:
o​ ​Request​ is sent to invoke the remote method.
o​ ​Reply​ is returned in response to ​Request.​ It normally contains the data,
 returned from the remote method. In other cases the reply may contain the
redirection instruction or the description of the exception that was thrown on a
server side.
o​ ​ ancelRequest​ is used to cancel a request that was previously sent (no
C
longer waiting for the answer).
o​ ​LocateRequest​ is used to verify that the server knows and supports the
certain remote object, and (if not), to what address the requests for that object
should be sent instead.
o​ ​LocateReply​ is sent by server in response to the ​LocateRequest.​ If needed, it
may contain the new address of the remote object that has moved.
o​ ​CloseConnection​ is sent by the server, indicating that it will not provide the
future responses.
o​ ​MessageError​ is sent in response to the malformed or otherwise invalid
messages. It is not used to report errors outside the messaging system; such errors
are reported using the ​Reply​ message.
o​ ​Fragment​ is a subsequent message, continuing the previous one. The long
messages can be split into fragments.

Binary format
In the binary dumps the GIOP message can be easily recognised by the characteristic header:
1. Four ASCII characters: G I O P
2. The two bytes, defining first major (currently only 1) and then minor version
numbers.
3. One byte, defining the message flags. The least significant bit defines the ​byte order
(0 - big endian, 1 - little endian).
4. One byte, defining the message type (​Reply​, ​Request,​ ​Fragment​ and so on).
5. The four byte word, defining the message size (not counting the message header).
Messages can also carry the arbitrary data fragments, identified by the standard integer tags.
These additional data fragments are called service contexts and are used to extend the
communication standard when necessary. There are standard ​service contexts​ to describe the
thrown exception, to specify the ​charset​ for representing the national characters and so on. It is
possible to register the client and server side interceptors that add the specific service contexts to
the messages being sent and also read the specific contexts, added by the similar ​interceptor​ on
the remote side.

Legal status of the GIOP abbreviation

CORBA​, IIOP and ​OMG​ are the registered trademarks of the Object Management Group and
should be used with care. Differently, the GIOP is ​not​ the registered OMG trademark (see ​list of
OMG trademarks​). Hence in some cases it may be more appropriate just to say that the
application uses or implements the GIOP-based architecture.

SOAP

SOAP​, originally defined as ​Simple Object Access Protocol​, is a ​protocol​ specification for
exchanging structured information in the implementation of ​Web Services​ in ​computer networks​.
It relies on ​Extensible Markup Language​ (XML) for its message format, and usually relies on
other ​Application Layer​ protocols, most notably ​Remote Procedure Call​ (RPC) and ​Hypertext
Transfer Protocol​ (HTTP), for message negotiation and transmission. SOAP can form the
foundation layer of a ​web services protocol stack​, providing a basic messaging framework upon
which web services can be built. This XML based protocol consists of three parts: an envelope,
which defines what is in the message and how to process it, a set of encoding rules for
expressing instances of application-defined datatypes, and a convention for representing
procedure calls and responses.
As a layman's example of how SOAP procedures can be used, a SOAP message could be sent to
a web-service-enabled web site, for example, a real-estate price database, with the parameters
needed for a search. The site would then return an XML-formatted document with the resulting
data, e.g., prices, location, features. Because the data is returned in a standardized
machine-parseable format, it could then be integrated directly into a third-party web site or
application.
The SOAP architecture consists of several layers of specifications: for message format, ​Message
Exchange Patterns​ (MEP), underlying transport protocol bindings, message processing models,
and protocol extensibility. SOAP is the successor of ​XML-RPC​, though it borrows its transport
and interaction neutrality and the envelope/header/body from elsewhere (probably from
WDDX​).​[​speculation?​]

SOAP structure

The SOAP specification

The SOAP specification defines the messaging framework which consists of:
 ·​ The ​SOAP processing model​ defining the rules for processing a SOAP message
·​ The ​SOAP extensibility model​ defining the concepts of SOAP features and SOAP
modules
·​ The ​SOAP underlying protocol binding​ framework describing the rules for
defining a binding to an underlying protocol that can be used for exchanging SOAP
messages between SOAP nodes
·​ The ​SOAP message construct​ defining the structure of a SOAP message
[​edit​]​ ​SOAP processing model
The SOAP processing model describes a distributed processing model, its participants, the
SOAP nodes​ and how a SOAP receiver processes a SOAP message. The following SOAP nodes
are defined:
·​ ​SOAP sender
A SOAP node that transmits a SOAP message.
·​ ​SOAP receiver
A SOAP node that accepts a SOAP message.
·​ ​SOAP message path
The set of SOAP nodes through which a single SOAP message passes.
·​ ​Initial SOAP sender (Originator)
The SOAP sender that originates a SOAP message at the starting point of a SOAP message path.
·​ ​SOAP intermediary
A SOAP intermediary is both a SOAP receiver and a SOAP sender and is targetable from within
a SOAP message. It processes the SOAP header blocks targeted at it and acts to forward a SOAP
message towards an ultimate SOAP receiver.
·​ ​Ultimate SOAP receiver
The SOAP receiver that is a final destination of a SOAP message. It is responsible for processing
the contents of the SOAP body and any SOAP header blocks targeted at it. In some
circumstances, a SOAP message might not reach an ultimate SOAP receiver, for example
because of a problem at a SOAP intermediary. An ultimate SOAP receiver cannot also be a
SOAP intermediary for the same SOAP message.

Transport methods
SOAP makes use of an internet ​application layer​ protocol as a ​transport protocol​. Critics have
argued that this is an abuse of such protocols, as it is not their intended function and therefore not
a role they fulfill well. Proponents of SOAP have drawn analogies to successful uses of protocols
at various levels for ​tunneling​ other protocols.​[​citation needed]​
Both ​SMTP​ and ​HTTP​ are valid application layer protocols used as Transport for SOAP, but
HTTP​ has gained wider acceptance as it works well with today's Internet infrastructure;
specifically, HTTP works well with network ​firewalls​. SOAP may also be used over ​HTTPS
(which is the same protocol as HTTP at the application level, but uses an encrypted transport
protocol underneath) with either simple or mutual authentication; this is the advocated ​WS-I
method to provide web service security as stated in the ​WS-I Basic Profile​ 1.1.
This is a major advantage over other distributed protocols like ​GIOP​/​IIOP​ or ​DCOM​ which are
​ MQP​ is yet another possibility that some
normally filtered by firewalls. ​SOAP over A
implementations support.

Message format
XML​ was chosen as the standard message format because of its widespread use by major
corporations and ​open source​ development efforts. Additionally, a wide variety of freely
available ​tools​ significantly eases the transition to a SOAP-based implementation. The somewhat
lengthy ​syntax​ of ​XML​ can be both a benefit and a drawback. While it promotes readability for
humans, facilitates error detection, and avoids interoperability problems such as byte-order
(​Endianness​), it can retard processing speed and can be cumbersome. For example, ​CORBA​,
GIOP​, ​ICE​, and ​DCOM​ use much shorter, binary message formats. On the other hand, hardware
appliances are available to accelerate processing of ​XML​ messages.​[3][4]​ ​Binary XML​ is also being
explored as a means for streamlining the throughput requirements of XML.

[​edit​]​ ​Sample SOAP message

POST /InStock HTTP/1.1
Host: www.example.org
Content-Type: application/soap+xml; charset=utf-8
Content-Length: nnn

<?xml​ ​version="1.0"?>
<soap:Envelope​ ​xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
​<soap:Header>
​</soap:Header>
​<soap:Body>
​<m:GetStockPrice​ ​xmlns:m="http://www.example.org/stock">
​<m:StockName>IBM</m:StockName>
​</m:GetStockPrice>
​</soap:Body>
</soap:Envelope>

[​edit​]​ ​Advantages
·​ SOAP is versatile enough to allow for the use of different transport protocols. The
standard stacks use HTTP as a transport protocol, but other protocols are also usable
(e.g., JMS​[5]​, SMTP​[6]​).
·​ Since the SOAP model tunnels fine in the HTTP get/response model, it can tunnel
easily over existing firewalls and proxies, without modifications to the SOAP protocol,
and can use the existing infrastructure.
[​edit​]​ ​Disadvantages
·​ Because of the verbose XML format, SOAP can be considerably slower than
competing ​middleware​ technologies such as ​CORBA​. This may not be an issue when
only small messages are sent.​[7]​ To improve performance for the special case of XML with
embedded binary objects, the ​Message Transmission Optimization Mechanism​ was
introduced.
·​ When relying on ​HTTP​ as a transport protocol and not using ​WS-Addressing​ or an
ESB​, the roles of the interacting parties are fixed. Only one party (the client) can use the
services of the other. Developers must use ​polling​ instead of notification in these
common cases.