[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsdm] MUWS - 2.1.2 Message Exchange Patterns
Geoff, relevant points wrt co-existence with firewalls. More details below. Geoff Bullen wrote: > > Hi all, > I remember as part of the discussion on this section it was suggested that > if we just specify that we need an asynchronous protocol, then you can > implement the single request/reply concept on top of this... so therefore > you don't need to specify both. > It is my belief that we definitely need to specify a direct request/response > protocol. There are a number of cases where using firewalls makes it quite > difficult to support asynchronous traffic (messages initiated from both > ends) rather than the simpler request/reply - where messages are only > initiated from one end. I think, specifically, maintaining a well-known (inbound) port on both sides and the connection being persistent should make things more firewall friendly. If we take the case of MUWS, then the inbound ports used across the firewall on either end are most likely to be 80, and we can be explicit about being able to work over HTTP1.1 and HTTP1.0 w/ Conn:Keep-Alive. There is still the issue of initiation of the connection, which typically should always be done from inside the firewall. But async messages sent over HTTP should not have this problem. [Correct me if my assumption is wrong here.] > I am not suggesting we should not support async, but I think you should be > able to create a management solution without it. Well, if we are to support async, then we have to address co-existence with firewalls. Given that the transport for WS is HTTP, we will be at the mercy of the idiosychracies (sp?) of this protocol wrt firewall-friendliness regardless of the range of message semantics (sync, async, req-reply) that we address. My $0.02! Sanjeev K.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]