'''Intent'''

Embed communication between two parties who use one protocol within the confines of another.

'''Motivation'''

This pattern can be used so an infrastructure built to support the second protocol doesn't have to change to support the first.  For clarity, we call the first contained protocol the "tunneled" protocol, and the second container protocol the "carrier" protocol.

When used with popular protocols like TCP/IP, the carrier protocol can exist at the same or higher level in the OSI model.

'''Known Uses'''

	PPTP[1]:	PPP is tunneled inside TCP to connect islands of an intranet (for example)

	IPIP[2]:	Can be used to move IP packets to a specific border router, where the real destination is unwrapped and treated appropriately.  Also used to carry IPv6 in IPv4 (perhaps a different protocol), and in MobileIp.

	HTTP-tunneled DCOM:	Yep, its happening here too.

-----

Question:   Why does it have to be at the same or higher OSI level?  What if they're both application-level according to OSI, but the "tunneled" one is logically lower-level than the other?  Is it still tunneling then?

A: "OSI" was used to modify "level" only to make the meaning of "level" clearer.  Perhaps it only clouded the issue.  Any protocol stacking model can be used in place of "OSI" above.  The point was to clarify that if the tunneled protocol is logically higher than the carrier protocol, then it is not tunneling but normal layering.

-----

The other question one might ask is, what does this have to do with ComponentBasedDevelopment?  It is a concept has been applied in cases inside and outside CBD.  One place I've seen ProtocolTunneling is with HTTP-tunneled DCOM.  Another is the FIX (Financial Information eXchange) protocol -- though it's not related to CBD, it can be tunneled through any suitable protocol for interbank exchange.

PhilipEskelin

-----

That's the thing that I'm trying to decide too.  The examples that I was thinking about were IIOP tunnelled through HTTP and (one I just heard of in a meeting last week) JDBC tunnelled through HTTP.  It seems quite common from what I've gathered.  That in itself probably makes it worthy of writing up, even if it doesn't make it into the CBD pattern language.

KyleBrown

----

I agree.  I had heard vaguely about IIOP tunneled through HTTP, but didn't have the knowledge or time to attain enough knowledge to include it as a known use.
JDBC through HTTP?--wow, that's a new one for me, but I can see why it might be useful.  Another would be when people add security in one way or another inside the protocol at hand.  Really, any meta stuff inside just plain using a protocol the way it's implemented can be considered tunneling.

I don't believe this pattern qualifies for ComponentDesignPatterns -- not because of its lack of utility, but because it transcends beyond component-oriented development.  But in a component-based development, you can use ProtocolTunneling like you use any random design pattern (say Singleton) to do your job better.

It seems the hip trend is to tunnel everything through HTTP.  I think this is because HTTP's infrastructure is so pervasive these days.  Soon, we'll see dinner etiquette being tunneled through HTTP ;-)

PhilipEskelin