Objctive 6.1: Given a scenario description, distinguish appropriate from inappropriate protocols to implement that scenario
IP, the basic protocol of the internet, enables the unreliable delivery of individual packets from one host to another. IP makes no guarantees about whether or not the packet will be delivered. TCP adds the notion of connection and reliability.
Port 80. Built on top of TCP/IP. Stateless, connection less and directional. Client opens a connection (using a URL – the direction) and sends request to the server, the server responds using the same connection, then the connection is closed. It is up to the client to optionally maintain the session (through cookies or URL re-writing).
Port 80. Same as HTTP 1.0 except there is an option to keep the connection alive from request to request. This would be known as connection oriented if it weren’t for the fact that either side can potentially drop the connection at any time (Apache does after 15 seconds), as such it is still ‘connection-less’. However, some people think it is connect oriented because you need a connection to be open to do a request at all. I disagree, but I get the impression this is what Sun thinks, I suppose that is what counts for the exam at least, it is very confusing.
Port 443. Adds security to HTTP. Supports the uses of X.509 digital certificates to authenticate the sender. 
SSL uses 40 or 128 bit key encryption. Encrypts both requests and responses. Also provides a maintenance of state from one request to the other.
Note: Not to be confused with S-HTTP, a security enhanced version of HTTP.
Light weight protocol for exchange of information in a decentralised, distributed environment. It is an XML based protocol. It can be used with other protocols for transport but typically this is HTTP(s).
Port 1099
Connection based
Supports pass by value (if Serializable or primitive) and pass by reference.
Java to Java only (Java 1.1) but using JNI can talk to/from other languages.
Need to run/expose a RMIRegistry
Compile Interface with rmic tool to get stubs and skeletons.
Easy to develop/use, portable, Java security and garbage collection.
Client needs to open a socket to the server.
Will tunnel over HTTP if cannot get through firewall.
Faster than RMI/IIOP because less generic.
Supports pass by value (in CORBA 2.3) else only data values (arguments and return types)
To allow CORBA services to use your services it is recommended you use RMI/IIOP, for example to access an EJB from a CORBA service.
Interoperate with other IIOP services - but only if remote I/Fs are defined as Java RMI I/Fs.
Legacy connectivity to CORBA (not always) plus also able to connect to RMI/JRMP, both.
Java-to-IDL mapping required (in CORBA 2.3).
Objects passed over not garbage collected – must manually ‘unexportObject’
Easier to program than Java IDL because uses RMI model.
An alternative to RMI/IIOP, same as normal CORBA programming – write the IDL, implement it, etc. business as usual.
Available in Java 1.2
To use an existing CORBA service it is recommended you use Java IDL.
Interoperate with non-Java services via IIOP.
Uses idlj (formally idltojava) compiler
Port 535
Interoperate with CORBA 2.0
Open standard are defined by OMG to avoid vendor lock-in.
IIOP includes embedded port and address information so hard to let through firewalls that are set up for ports and addresses in TCP/IP protocol.
Allows call backs, the client opens a connection to the server, and the server opens a connection back to the client for the response.
Pre-CORBA 2.3 can only pass data values and return types not actual objects.
Heavily used on Windows.
There are CORBA to DCOM bridges.
Very similar to CORBA.
Uses DCOM IDL for interface definition.
Supports multiple interface inheritance
GUID in interface to uniquely identify it.
Uses Windows registry as naming service.
Port 21. 
Used to copy files between computers-usually a client and an archive site. It's old-fashioned, it's a bit on the slow side, 
it doesn't support compression, and it uses cryptic Unix command parameters. But the good news is that you can download free apps that 
shield you from the complexities of Unix, and you can connect to FTP sites using a Web browser.
Port 110. The current champ in Internet e-mail mailbox access standards, but its limitations -basically, you connect to a server and download all your messages, which are then deleted from the server-discourage flexibility. Of course, some clients let you leave all messages on the server, and/or refuse to download messages above a certain size. Still, as messages become longer-with multimedia (such as sound or video) objects and the likes-we'll want some flexibility in what we retrieve and when we retrieve it.
Port 143.
IMAP provides a means of managing e-mail messages on a remote server, similar to the POP protocol. But IMAP offers more options than POP, 
including the ability to download only message headers, create multiuser mailboxes, and build server-based storage folders.
Port 25.
Used to send e-mail messages.