apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Preethi Natarajan <natar...@cis.udel.edu>
Subject Re: APR with SCTP streams.
Date Tue, 15 Nov 2005 23:50:34 GMT

As per earlier discussion, I am trying to merge my changes with the latest 
APR trunk. I got this through
svn co http://svn.apache.org/repos/asf/apr/apr/trunk/

I am not able to get the configure script from configure.in :
complains about AC_PROG_LIBTOOL; I tried to work around that then there 
were complains about apr_private_h.in not being found; I cannot do a 

I would like to know if I am using the correct URL for the trunk. 
Are there daily "compilable" snapshots that are available for patch 
creatiion ?


On Tue, 25 Oct 2005, Preethi Natarajan wrote:

> On Tue, 25 Oct 2005, Colm MacCarthaigh wrote:
>> brilliant source of working code - I've tested it a little). Is there
>> any reason why the stream id could not just be member of apr_socket_t,
>> and handled by the existing functions?
> I had started with that idea but couldnt conitnue with it since ideally 
> different HTTP reqs can come in different SCTP streams in the _same_ 
> apr_socket_t. So the stream info will be overwritten after each request.
> In that case, the response and req could end up in different SCTP streams.
> However, I faced another problem in httpd for which I changed the design so 
> that another request can be read only after the response to prev req has been 
> sent. (I can elaborate further if there is interest). So now, I can put in 
> the stream info in apr_socket_t. Will that be better?
>> I'm not sure that port/protocol parsing as indiciated belongs in APR
>> either. But great to see work on SCTP!
> I saw that apr_parse_addr_port was called by listen.c to read the addr and 
> port from the Listen directive. This function has to be changed too since the 
> new Listen directive can have protocol as an argument.
>> -- 
>> Colm MacCárthaigh                        Public Key: colm+pgp@stdlib.net
  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message