Hello, Attached are the modifications to APR to make it use SCTP (Stream Control Transmission Protocol RFC2960) streams. This patch (svn diff) is against the main APR trunk.
For more details on the work, http://issues.apache.org/bugzilla/show_bug.cgi?id=37202) Overview of the modifications: * Added a "sctp_stream_id" member to unix/apr_socket_t structure. * Chnages in unix sendrecv.c sockets.c to handle SCTP with streams sockets. * Added an extra function in unix sockaddr.c to parse the Listen directive with transport protocol as an extra argument. * Changes to configure.in to detect sendmsg/recvmsg in the system. Thanks, Preethi 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: [EMAIL PROTECTED]
APR_SCTP_Streams_patch.DEFANGED-18694
Description: Renamed from 'APR_SCTP_Streams_patch' to 'APR_SCTP_Streams_patch.DEFANGED-18694'
