Jeff:
Ok I just stole a few cycles and had a look... some quick comments.
1) In the network_io/win32/sockets.c
the call from apr_socket_create() to -> apr_socket_create_ex()
is going to not compile since you put in a variable "protocol" which is not defined in the function.. I think you meant to put '0' in here like you did in the other 2.
2) The change in apr_os_sock_put to specify TCP is, IMO, the wrong thing to do... A quick check of cscope in httpd shows 6 users of this call and of those 6, 4 of the uses are for NON-TCP sockets (at least I think they are.. called things like the "pipe of death" etc. Of the 2 that use TCP .. once SCTP shows up this will cause some problems (at least in the mpm files). They are passing the listener sockets to the child and setting them. One of them knows the protocol (if it cared to get it) the other does not.. and I would imagine will need to send it...
Maybe for now just specifying '0' .. or maybe we need a APR_PROT_UNKNOWN -> 0... definition. Sigh.. ugly either way..
R
Jeff Trawick wrote:
Randall Stewart <[EMAIL PROTECTED]> writes:
Dear all:
I attach the option 1 patch... aka add the call apr_socket_create_protocol() to the apr. This causes the smallest amount of change to the apr.
An initial patch to support protocols in general is committed. Please check over and complain appropriately before I go through the rest of your patch.
deferred temporarily: locating sctp headers, setting APR_HAVE_SCTP, special socket option
support for SCTP
deferred until we prepare for 1.0: protocol support for apr_os_sock_make (since that would break binary compatibility since the structure is extended and I don't think it is necessary to have temporary apr_os_sock_make_ex and temporary apr_os_sock_info_ex_t)
changed: kernel continues to choose proto if app doesn't choose hard-code numeric values for the several protocols
enhanced: test/server.c makes sure desired protocol is preserved from listening socket to connected socket
I've got some high priority Apache testing to do this a.m., but hopefully in the next day or so I can get to the parts of your patch which I temporarily deferred, and meanwhile you can look out for screwups or other problems in what I just committed.
Thanks,
-- Randall R. Stewart [EMAIL PROTECTED] 815-342-5222 (cell phone)
