Mailing-List: contact axis-c-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache AXIS C Developers List" <axis-c-dev@ws.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <4153B350.8090900@cs.indiana.edu>
Date: Fri, 24 Sep 2004 00:40:32 -0500
From: Aleksander Slominski <aslom@cs.indiana.edu>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
MIME-Version: 1.0
To: Apache AXIS C Developers List <axis-c-dev@ws.apache.org>
Subject: Re: Analysis of Axis C++ client transport
References: 
 <OF0935D164.B6DD14A8-ON80256F18.00386F66-80256F18.00387D48@uk.ibm.com>
 <0b4501c4a189$c1f22580$90414109@LANKABOOK> <415307C5.3@cs.indiana.edu>
 <0cd101c4a1e6$73c35e30$90414109@LANKABOOK>
In-Reply-To: <0cd101c4a1e6$73c35e30$90414109@LANKABOOK>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Sanjiva Weerawarana wrote:

>"Aleksander Slominski" <aslom@cs.indiana.edu> writes:
>  
>
>>i though that AXIS/Java is doing chunking as tomcat4/5 will see HTTP/1.1 
>>and assume that client can support it?!
>>    
>>
>
>Axis/Java only sends one chunk .. and its Tomcat that's doing that,
>not Axis/Java.
>  
>
isn't it what exactly should be happening in AXIS/C++ that should use on 
server side apache to do chunking and on client side use library to do 
chunking - good transport layer should care of all those details on SOAP 
level you just give it a chunk (or stream) that you want to send?

>>there is other side to this argument: as messages do not need to be sent 
>>right away and are most likely one-way (as this is message-oriented 
>>model) you can gather multiple messages with he same host:port 
>>destination (possibly targeted to multiple services on the same 
>>host:port or even more likely targeted to go through the same 
>>firewall/proxy server on intranet border) and then push them all over 
>>one keep-alive/chunked connection - that should be very efficient 
>>especially if you are sending lot of small messages ...
>>    
>>
>
>You're proposing using box-carring 
>
not at all - i do not want to send one giant SOAP message but use 
KeepAlive/chunking to reuse one TCP connection to send *multiple* SOAP 
messages- this is simple transport optimization similar to in spirit to 
Nagle Algorithm that delays sending of TCP packet to try to minimize 
overhead sending of just one character (of just one message).

>.. yes that can be more efficient
>but you have to consider RM too. In some sense the boxcarring model
>makes sense if you have lots of apps on one server all talking to
>a bunch of services on *one* other server. Then you can share one http
>connection and do stuff.
>  
>
RM will work just fine as what i though about is just an optimization on 
HTTP transport level and has nothing to do with messaging level

>Ever heard of BEEP? 
>
yes - good idea but too complicated protocol that never really gained 
popularity (maybe because it was too hard to implement ...)

>That's the right way to do this right :)
>
in principle yes but i would prefer more lightweight solution ...

> .. you
>can establish one connection and do lots of chats inside that one
>thing without being restricted to boxcar a bunch of one-way stuff.
>  
>
it is what TCP/IP initially was before firewalls/NAT/... and 
asymmetrical HTTP request/response: two peers each with unique IP 
addresses that could send to each other whatever and open any number TCP 
connection s ...

>  
>
>>i think that should be configurable: when using HTTP/1.0 just open 
>>connection, write output, close and with HTTP/1.1 use KA and chunking ...
>>    
>>
>
>Yes that's fine - supporting 1.0 from the new transport should be 
>a start. 
>
and well tested.

>Next we can move to 1.1 and add support for chunking 
>incrementally and then KA.
>  
>
agreed.

thanks,

alek

-- 
The best way to predict the future is to invent it - Alan Kay