RE: Protocol Bindings

Hi Marshall,

>    head-of-line blocking goes away when you do segmentation
>and allocations, the cost is that you sacrifice the ability to 
>operate at TCP's theoretical speeds.

Regardless of segmentation, you cannot avoid outstanding data ahead of
you having to be drained first. Additionally, in order to get reasonable
response time from a channel, you would want fairly small segments,
leaving applications having to cut their data into small pieces.

>    deadlocks, as a potential problem, exist independently --
>either due to poor protocol design or poor protocol implementation.

An annoying aspect of communicating with somebody is that you don't
quite have control over how they react or how many resources they have
available :) Because channels are inherently interrelated it is always
possible to provide scenarios where a particular segmentation/allocation
policy gets in the way and can lead to unexpected deadlock situations
regardless of good intentions.

>    channel aborts can be handled with prioritization of a
>control channel.

Indeed but again, outstanding data will have to get drained which you
effectively have little control over how long that might take. In
general the purpose of channel aborts is to return the resources used as
quickly as possible.

>none of this is rocket-science, it just requires careful
>engineering and reasonable implementation.

Certainly it can be done but it seems to me to be a slippery slope - in
order to implement these mechanisms you will end up having to
reimplement much of what TCP already provides and a session layer seems
to me to be the wrong place to do that.

>as for the benefits:
>    when you are able to amortize the cost of connection
>establishment, security neogitation, and state restoration for 
>transactions involving more than one exchange, the benefits 
>become noticable.

I see but tying application state to a particular transport or session
channel doesn't seem like a good idea to me. I can't see why state
cannot be maintained in the endpoints without having any specific link
to the underlying transport.

>    when you are able to operate asynchronously in a
>loosely-coupled system, the benefits become noticable.

Absolutely - I just don't think it takes a complex session layer to get
there. By supporting bi-directional messaging over a single TCP
connection and then use multiple TCP connections for handling message
interleaving, I think I get what I need:

	    ---->        <----      ---->        <----
	   +-----+      +-----+    +-----+      +-----+
	<--|msg 2|------|msg A|----|msg 1|------|msg B|--> TCP 1
	   +-----+      +-----+    +-----+      +-----+

	    ---->        <----      <----        <----
	   +-----+      +-----+    +-----+      +-----+
	<--|msg 3|------|msg C|----|msg D|------|msg D|--> TCP 2
	   +-----+      +-----+    +-----+      +-----+

>> If you want to have that flexibility then why not simply do
>> SOAP-RP/DIME over multiple TCP streams?
>
>because, in today's operational environments, if you originate
>two tcp connections to the same ip address at the same time, 
>you have no guarantee that they terminate at the same system. 
>10 years ago, this wasn't an issue...

This only seems to reinforce my comments about it not being a good idea
to associate application state with the underlying transport.

>regardless, when you do multiple tcp connections, then there's
>a whole other set of problems that pop up with firewalls, 
>viz., ftp-data for the simple case...

No argument there either but I can't see that this is an argument for a
session layer. If we already have bi-directional messaging and I really
want more than one TCP connection then why can I not ask the party that
established the first connection to establish one more?

Henrik

Received on Sunday, 8 July 2001 15:23:12 UTC