PROTOCOLS NOTES
Author: RAMU MEDA
Date: 01/sep/03
Port overview
Standard port
21
23
25
80
88
110
119
135
161
389
443
636
993
1099 ( Naming)
8001/538 ( Naming )
Protocol/Service
FTP
telnet
SMTP
HTTP
Kerberos/UDP
POP3
NNTP/TCP
RPC/TCP
SNMP
LDAP
HTTPS
LDAPS
SSL
JRMP
IIOP
Comment
File transfer protocol
Remote login
Simple mail transfer protocol
WWW transmission protocol
Post office protocol
Simple network management protocol
Lightweight directory access protocol
HTTP/SSL
LDAP over SSL
Secure Socket Layer
Java remote method protocol
Internet Inter-Orb Protocol
Scenarios:
 HTTP/HTTPS – internet sites
 RMI-IIOP – intranet environment; interoperability requirements (EJB-EJB, EJB-CORBA, etc.)
 RMI-JRMP – intranet with an all Java environment
Firewalls: Firewalls provide protection by:
 packet filtering
o IP blocking – source or destination IP
o Port blocking – e.g. only allow well-known ports such as 80, 443, 25, etc.
 protocol filtering – e.g. no FTP
 HTTP/HTTPS aren’t generally affected by firewalls as ports 80 and 443 are normally allowed
through. However, HTTP clients cannot generally accept asynchronous updates (push model) as
more than likely the client will be prevented from running a socket server.
 Most of the time, IIOP and JRMP are affected by firewalls as they use dynamic port allocation for
object servers and use less well-known ports.
 Although IIOP and JRMP can be tunneled through HTTP this isn’t ideal – the main benefit of being
connection-based protocols is then lost.
HTTP
 The HTTP protocol is based on a request/response paradigm.
 The communication generally takes place over a TCP/IP connection on the Internet.
 The default port is 80, but other ports can be used. This does not preclude the HTTP/1.0 protocol from
being implemented on top of any other protocol on the Internet, so long as reliability can be
guaranteed.
 The HTTP protocol is connectionless and stateless After the server has responded to the client's
request, the connection between client and server is dropped and forgotten. There is no "memory"
between client connections. The pure HTTP server implementation treats every request as if it was
brand-new, i.e. without context.





An extensible and open representation for data types HTTP uses Internet Media Types (formerly
referred to as MIME Content-Types) to provide open and extensible data typing and type negotiation.
HTTPS(Secure Hypertext Transfer Protocol)
HTTP1.0 uses tear-down
o Client opens/closes socket connection to the web server every time
HTTP1.1 uses keep-alive (a persistent connection).
o Client holds socket connection open over multiple requests.
o Still regarded as connection-less as it’s acceptable for the client or server to drop the
connection at any time (e.g. Apache uses a 15 sec timeout on keep-alive sockets), client will
re-establish the connection.
o Client/server can use pipelining – i.e. sends multiple requests/responses down the socket at
once.
Pros:
o simple request/response mechanism
o allowed through firewalls (most of the time)
o widely supported / deployed
o extensible - supports tunneling of arbitrary data;
o custom request types/response content
Cons:
o stateless - hence non-transactional
o insecure - hence HTTPS
o inefficient - e.g. MIME encoding can make files bigger
o doesn’t support “push” model
HTTPS











Stateful / connection-based.
Web protocol developed by Netscape and built into its browser that encrypts and decrypts user page
requests as well as the pages that are returned by the Web server.
HTTPS is really just the use of Netscape's Secure Socket Layer (SSL) as a sublayer under its
regular HTTP application layer.
HTTPS uses default port 443 instead of HTTP port 80 in its interactions with the lower layer,
TCP/IP.
SSL uses a 40 or 128-bit key size for the RC4 stream encryption algorithm, which is considered an
adequate degree of encryption for commercial exchange.
URL that starts with https://. When you click "Send," to send the page back to the catalog retailer,
your browser's HTTPS layer will encrypt it. The acknowledgement you receive from the server will
also travel in encrypted form, arrive with an https:// URL, and be decrypted for you by your browser's
HTTPS sublayer
HTTPS and SSL support the use of X.509 digital certificates from the server so that, if necessary, a
user can authenticate the sender.
SSL is an open, nonproprietary protocol that Netscape has proposed as a standard to the World Wide
Consortium (W3C).
HTTPS is not to be confused with SHTTP, a security-enhanced version of HTTP developed and
proposed as a standard by EIT.
Pros:
o secure – only “in-the-clear” at client / server
o allowed through firewalls (most of the time)
o widely supported / deployed
Cons:
o computationally expensive – excluding dedicated hardware, HTTPS can only process 10% of
the traffic HTTP can
o low performance compared to HTTP
o Admin overhead – renewing certs, etc.
2



Each party (client/server) may hold multiple SSL sessions.
Each session may include multiple secure connections.
SSL handshake Process :
o The client and server exchange capabilities (e.g. SSL version, ciphers available, etc.). The
server includes it’s certificate in the response
o client verifies the CA’s digital signature in the server certificate using the CA’s public key
o if OK, the client generates a pre-master secret, encrypts it using the server’s public key and
sends it to the server [if using client certificates, the client response includes the pre-master
secret and the client certificate. The server verifies the CA’s digital signature in the client
certificate using the CA’s public key]
o the server decrypts the pre-master secret using it’s private key
o using the pre-master secret, the client and server use an agreed algorithm to independently
generate the master secret
o the master secret is then used to generate a set of session keys (symmetric keys for speed)
o the client and server exchange messages confirming that the encrypted session has started.
Subsequent SSL records are compressed and encrypted / signed using the session keys
Note on Dashed line in the above figure: An RMI-IIOP client cannot necessarily access all existing CORBA
objects. The semantics of CORBA objects defined in IDL are a superset of those of RMI-IIOP objects, which is
why an existing CORBA object's IDL cannot always be mapped into an RMI-IIOP Java interface. It is only when
a specific CORBA object's semantics happen to correspond with those of RMI-IIOP that an RMI-IIOP client can
call a CORBA object. The dotted arrow indicates a connection that is sometimes -- but not always -- possible.
IIOP / RMI-IIOP









Stateful / connection-based.
no default port – the GIOP/IIOP implementation will dynamically assign ports when an object server
instance binds to a name
CORBA and IIOP assume the client/server model of computing in which a client program always
makes requests and a server program waits to receive requests from clients.
GIOP  CDR formatting rules + Message formats + message-transport assumptions.
IIOP (InterObject Internet protocol)  General Inter-ORB Protocol (GIOP) + TCP.
Interoperable Object Reference (IOR)  address for the program ( part of the address is based on the
server's port number and Internet Protocol (IP) address ). The IOR contains a set of profiles (details of
host, port, object instance, etc.) so that a client knows where to connect / send messages back and
forth.
Common Data Representation (CDR) provides a way to encode and decode data so that it can be
exchanged in a standard way.
CORBA is not the only architecture that uses IIOP
CORBA is an integration technology, not a programming technology. It is specifically designed to be
the glue that binds disparate programming technologies together
3






RMI-IIOP  RMI+CORBA  combines RMI's easy programming features + CORBA's
interoperability
Pros:
o supports propagation of security/transactional context
o an open standard from the OMG
o Mostly used for intranets / extranets – i.e. clients behind corporate firewalls or VPN
connections Clients communicate with servers via an IOR (Interoperable Object Reference).
o Interoperability – Java clients can call C++ servers; Cobol client can call Java server, etc.
o Legacy integration
o Designed for generic remote object invocation - type safe, extensible
o Inbuilt support for security and transactions
o CORBA and IIOP also guarantee that objects can describe their interfaces at run-time. The
ability to do this in object and component models is often called "introspection." This
capability allows users much more powerful browsing capabilities. Rather than just
downloading documents, users can interactively discover and inquire about a wider range of
more sophisticated object services.
Cons:
o Firewalls – servers bound to arbitrary ports so firewall can’t be configured with an IIOP port;
can use HTTP Tunneling. Can be supported with an IIOP proxy but “push” model is still
problematic
o Performance – all method invocations are remote (possibly over the internet)
o Pass-by-reference – only supports remote references, can’t use pass-by-value (until CORBA
2.3)
The two major changes CORBA accepted were the Objects by Value and the Java-to-IDL Mapping
specifications. The former, already available to RMI users in the form of Java object serialization, is a
CORBA specification intended to make other languages implement a similar capability. The latter is
the mapping used to convert RMI Java interfaces into CORBA IDL definitions, and must not be
confused with the IDL-to-Java mapping already defined in CORBA 2.2.
RMI-IIOP client cannot necessarily access an existing CORBA object. If you do want to use Java to
access CORBA objects that have already been written, Java IDL is an alternative to RMI-IIOP. Using
Java IDL (a core part of the Java 2 Platform), you can access any CORBA object from Java.
Sun's recommendation for usage of RMI-IIOP and Java IDL.
 If you want to use Java to access existing CORBA resources, Java IDL is recommended.
 If, conversely, you want to export Java RMI resources to CORBA users, you should use
RMI-IIOP.
JRMP





Also known as the RMI Wire Protocol, to send method invocations and associated parameters and to
return values and exceptions from one Java virtual machine (JVM) to another.
JRMP is the default protocol for RMI – stateful / connection-based.
JRMP is a simple protocol consisting of five messages, plus an extra five for multiplexing flow
control.
The default port for the RMI registry / JNDI name server is 1099, object servers will be dynamically
assigned ports by the RMI runtime.
Pros:
 Richer feature set than IIOP
 pass by reference or by value;
 distributed GC;
 stub download ,
 Single multiplexed connection
 allows to move code ( behaviour) in addition to data (state)
 Data type can be any Java objects. Any Java objects can be passed as arguments. Arguments
has to implement the serializable interface
 carries Java's security model to ensure that the code downloaded is safe to run
 allows pass by value references
4



Cons:
o
o
o
uses Java as both an interface definition and an implementation language
uses a URL-based naming scheme
Firewalls – servers bound to arbitrary ports; TTP tunneling limited
Performance – all method invocations are remote (possibly over the internet)
RMI lacks followings with respect to IIOP








Interoperability - only works in a Java environment In other words, RMI objects can
talk only to other RMI objects. With RMI, you cannot invoke objects written in
other languages or vice versa.
Dynamic invocations and interface repositories.
Wire protocol for security and transactions. RMI is both proprietary and lightweight.
It was not designed to interoperate with other ORBs or languages. Unlike CORBA's
IIOP, RMI is not a suitable backbone for the Internet or intranets; it lacks services
IIOP provides.
Unlike CORBA, RMI offers no concept of services
RMI also does not include any object activation policies, such as those used by
CORBA ORBs.
server objects written in Java using RMI suffer from poor performance due to
limitations inherent in the Java virtual machine
While RMI is a viable option for smaller-scale applications to be written entirely in
Java, CORBA provides the foundation for integration of existing objects with new
code and also the ability to scale for the future
Lacks IIOP’s support for transaction/security context propagation ( RMI has only the
naing service. CORBA has support for Naming, Security, Transactions, Events and
Concurrency control )
5