apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randall Stewart <rand...@stewart.chicago.il.us>
Subject Re: Patch option 1 - with apr_socket_create_protocol()
Date Fri, 18 Oct 2002 13:03:32 GMT
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 <randall@stewart.chicago.il.us> 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
randall@stewart.chicago.il.us 815-342-5222 (cell phone)


Mime
View raw message