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: [EMAIL PROTECTED]
