On Mon, Feb 26, 2001 at 11:39:51PM +0000, Wez Furlong wrote:
> When opening a socket there are 3 stages (and thus operations on the socket):
>
> 1. Create a socketd of appropriate domain/type/family (socket(2))
> 2. resolve the address to connect to (domain specific)
> 3. make the connection (connect_nonb)
The resolving isn't always done with a socket.
> If we bring this together (and borrow from fopen_wrappers) we can have an extensible
>socket abstraction, where the protocol part of the hostname from the fsockopen call
>determines which underlying socket family to use.
But with for instance IPv6, you won't know what socket you need until
you're done with the resolving. That's why hostconnect() is like it
is. It even needs to connect before it knows what socket to use. That
is, it creates a socket for each connect (which may be AF_LOCAL,
AF_INET, AF_INET6), but returns with one socket in the end, after a
successfull connect. I think hostconnect() shouldn't use sockbuf
for it's work, but should return a sockbuf, probably with default
ops filled in, the caller can if it likes replace the ops with
it's own, currently only SSL perhaps. Some future use could be
compression perhaps, don't know.
I'm not convinced we should put socket(), resolve() etc. into the
structure. I agree that we need those, and others, but I don't see
the value of putting them in a structure.
For SSL it should be possible to connect() as usual using
hostconnect() and then do the SSL negotiation, right?
> The protocol name would map to a php_socket_ops structure, which might look
>something like this:
>
> struct php_socket_ops {
> int (*socket)(void ** cookie, socklen_t * addrlen);
> int (*resolve)(void * cookie, struct sockaddr * addr, char * hostname, unsigned
>short port);
> int (*connect)(void * cookie, struct sockaddr * addr, struct timeval * timeout);
> int (*strerror)(void * cookie, int errno, char * buf, size_t buflen);
> int (*close)(void * cookie);
> size_t (*read)(void * cookie, char * buf, size_t buflen);
> size_t (*write)(void * cookie, char * buf, size_t buflen);
> };
close, read and write is fine, we need that abstraction. I think
perhaps we should have destruct() rather than close() where close()
first calls destruct to let for instance SSL clean up whatever is
needed, and then do the normal socket close and free the php_sockbuf
structure. By abstracting read and write, it could be possible to
put fopen_wrappers in extensions (completely modularized), seems
sensible to me to put the SSL wrapper in the openssl extension.
I think we need the sockbuf abstraction, so I agree on the general
lines.
Stig
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
