Re: [PHP-DEV] SSL -> joining sockets and files

[Wez Furlong]

On 2001-03-01 05:14:18, Andi Gutmans <[EMAIL PROTECTED]> wrote:
> This sounds pretty good. I'll try and look at the code this weekend. Some 
> of the code is really ugly especially the legacy code.
> When you say there are places which need a FILE * do you mean they just 
> need to check the id and check that it's a FILE * or do they convert 
> descriptors to FILE * (can't remember if that's possible or not :).

A bit of both.  the fopen_wrapper_for_zend (or whatever it's called) use
fdopen in this way, but mostly the code can be changed to use the
file abstraction.

Using fdopen might be problematic when SSL is concerned, unless we use
fopencookie to provide a FILE *.
Some extensions might need to pass a FILE * to library functions, so
perhaps we should add a php_file_cast_to_FILE() function.

It might work something like this:

// and also a similar version for sockets
typedef struct _php_file_FILE {
php_file ops;
FILE * file;
} php_file_FILE;

FILE * php_file_cast_to_FILE(php_file * file)
{
// if it can be expressed as a FILE, pass it back
if (file->type & PHP_FILE_IS_FILE)
return ((php_file_FILE*)file)->file;
// if it is a socketd, use fdopen
if (file->type & PHP_FILE_IS_SOCKET)
return fdopen(((php_file_socket*)file)->socket);
#if HAVE_FOPEN_COOKIE
// Create a generic fopen cookie that uses our abstraction
... code omitted for brevity ...
#endif
return NULL;
}

For systems without fopencookie, you will still only be able to use regular FILE or 
socketds in this way, but with fopencookie present, you can pretty much do anything 
you want.  Also, we can isolate the fopencookie code to just this one place and the 
rest of the codebase will be more portable.

A problem with the above it that in the case of fdopen we don't record that
we handed out a FILE *.  We can solve that by keeping the reference stashed somewhere 
in the php_file.  Another problem that might arise is if the code uses a mixture of 
stdio and php abstraction functions and the FILE has buffering turned on.
So, if we have created a FILE using fdopen or fopencookie, maybe we should switch the 
operations to use the stdio versions on that FILE?

--Wez.


--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] SSL -> joining sockets and files

[Stig Venaas]

On Thu, Mar 01, 2001 at 07:14:18AM +0200, Andi Gutmans wrote:
> This sounds pretty good. I'll try and look at the code this weekend. Some 
> of the code is really ugly especially the legacy code.

Yes, I like it too, and it is something I've been halfway thinking of
myself because of IPv6. Some of this will help IPv6 since I need to
know if a socket is AF_INET, AF_LOCAL or AF_INET6 when it's passed
around. Currently getsockname is used in socket.c, Sascha and me were
thinking of a solution a bit like this.

I also like the thought of modularizing fopen-wrappers completely,
in the future it could be possible to say dynamically load modules
(PEAR or whatever) depending on the URL scheme.

Busy with other fun programming projects at the moment,

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] SSL -> joining sockets and files

[Andi Gutmans]

Too early in the morning. I just remembered fdopen() :)

Andi

At 07:14 AM 3/1/2001 +0200, Andi Gutmans wrote:
>This sounds pretty good. I'll try and look at the code this weekend. Some 
>of the code is really ugly especially the legacy code.
>When you say there are places which need a FILE * do you mean they just 
>need to check the id and check that it's a FILE * or do they convert 
>descriptors to FILE * (can't remember if that's possible or not :).
>
>Andi
>
>At 02:12 AM 3/1/2001 +, Wez Furlong wrote:
>>I've just looked through the code.
>>
>>
>>
>>The current issock stuff is a bit of a nightmare, but not too much of a 
>>problem.
>>
>>
>>
>>Most of the codebase seems to be fairly well behaved with FP_FGETS and 
>>friends (apart from the interbase extension, where it does the same thing 
>>as FP_FREAD without using FP_FREAD).
>>
>>
>>
>>The aim is to reduce three parameters to a single parameter for the FP_ 
>>family of macros.
>>
>>Ideally, it would be nice to do this for php_fopen_wrapper as well, and 
>>have it return the "php_file" abstraction we are proposing.  I'm not sure 
>>how well people will like this
>>
>>in general, but thats why I'm talking about it and not changing the code 
>>right now.
>>
>>
>>
>>Whenever an extension needs to open a file it also needs to complain if 
>>it can't open it.
>>
>>All over the code we have the same checks to see if it is a socket or a 
>>file, if it was opened, and if if wasn't complain, but first strip out a 
>>password from the filename/url etc. etc.
>>
>>
>>
>>A suggestion is this:
>>
>>
>>
>>typedef struct _php_file {
>>
>>  int file_type; /* bitfield: PHP_FILE_STDIO, PHP_FILE_SOCKET */
>>
>>  int (*write)(php_file *this_ptr, );
>>
>>  int (*read)(php_file *this_ptr,);
>>
>>  int (*open)(php_file *this_ptr,);
>>
>>  int (*close)(php_file *this_ptr,.);
>>
>>  int (*seek)(php_file * this_ptr, ...); /* useful */
>>
>>} php_file;
>>
>>
>>
>>php_file * php_fopen_wrapper(char * filename, char * mode,
>>
>>  int options,
>>
>>  char ** opened_path,
>>
>>  int report_error
>>
>>  );
>>
>>
>>
>>Basically the same as the current implementation except that it returns 
>>an abstraction rather than a bunch of alternatives.
>>
>>The report error flag will cause the fopen wrapper to display the error 
>>message using the current active function name from the scripting engine, 
>>saving a few lines of code for each call where error reporting is 
>>required, and increasing maintainability.
>>
>>
>>
>>This is going to break code in 11 files, but that is relatively easy to fix.
>>
>>
>>
>>Some code requires that we get a FILE * back (the fopen_wrapper_for_zend 
>>is one), and some requires a socket (the code in fsock.c), so we need a 
>>way to get those out of the php_file:
>>
>>
>>
>>FILE * PHP_FILE_GET_STDIO_FILE(php_file *)
>>
>>int PHP_FILE_GET_SOCKETD(php_file *)
>>
>>
>>
>>[the names could be PHPFILEGETSTDIOFILE, but thats a different thread... ;-)]
>>
>>
>>
>>These could be implemented as macros, provided that all stdio based 
>>abstractions "descend" from a common structure where the FILE * lives at 
>>the same structure offset, and likewise for the socketd versions.  In the 
>>common case, there will only be one of each of these types anyway.
>>
>>
>>
>>I don't think that any of this will have a special impact on win32 
>>platforms (any more than unix), because we are too high level for that.
>>
>>
>>
>>The only real problem is cleaning up the code to use the php_file 
>>abstraction instead of assuming it's getting a stdio fp back.
>>
>>
>>
>>Once all this is done, the SSL code could be written as an fopen wrapper.
>>
>>
>>
>>I'm getting tired, so I may have overlooked something glaringly obvious; 
>>please let me know if
>>
>>I have, or if you have any other suggestions or improvements.
>>
>>
>>
>>--Wez.
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>To contact the list administrators, e-mail: [EMAIL PROTECTED]


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] SSL -> joining sockets and files

[Andi Gutmans]

This sounds pretty good. I'll try and look at the code this weekend. Some 
of the code is really ugly especially the legacy code.
When you say there are places which need a FILE * do you mean they just 
need to check the id and check that it's a FILE * or do they convert 
descriptors to FILE * (can't remember if that's possible or not :).

Andi

At 02:12 AM 3/1/2001 +, Wez Furlong wrote:
>I've just looked through the code.
>
>
>
>The current issock stuff is a bit of a nightmare, but not too much of a 
>problem.
>
>
>
>Most of the codebase seems to be fairly well behaved with FP_FGETS and 
>friends (apart from the interbase extension, where it does the same thing 
>as FP_FREAD without using FP_FREAD).
>
>
>
>The aim is to reduce three parameters to a single parameter for the FP_ 
>family of macros.
>
>Ideally, it would be nice to do this for php_fopen_wrapper as well, and 
>have it return the "php_file" abstraction we are proposing.  I'm not sure 
>how well people will like this
>
>in general, but thats why I'm talking about it and not changing the code 
>right now.
>
>
>
>Whenever an extension needs to open a file it also needs to complain if it 
>can't open it.
>
>All over the code we have the same checks to see if it is a socket or a 
>file, if it was opened, and if if wasn't complain, but first strip out a 
>password from the filename/url etc. etc.
>
>
>
>A suggestion is this:
>
>
>
>typedef struct _php_file {
>
>  int file_type; /* bitfield: PHP_FILE_STDIO, PHP_FILE_SOCKET */
>
>  int (*write)(php_file *this_ptr, );
>
>  int (*read)(php_file *this_ptr,);
>
>  int (*open)(php_file *this_ptr,);
>
>  int (*close)(php_file *this_ptr,.);
>
>  int (*seek)(php_file * this_ptr, ...); /* useful */
>
>} php_file;
>
>
>
>php_file * php_fopen_wrapper(char * filename, char * mode,
>
>  int options,
>
>  char ** opened_path,
>
>  int report_error
>
>  );
>
>
>
>Basically the same as the current implementation except that it returns an 
>abstraction rather than a bunch of alternatives.
>
>The report error flag will cause the fopen wrapper to display the error 
>message using the current active function name from the scripting engine, 
>saving a few lines of code for each call where error reporting is 
>required, and increasing maintainability.
>
>
>
>This is going to break code in 11 files, but that is relatively easy to fix.
>
>
>
>Some code requires that we get a FILE * back (the fopen_wrapper_for_zend 
>is one), and some requires a socket (the code in fsock.c), so we need a 
>way to get those out of the php_file:
>
>
>
>FILE * PHP_FILE_GET_STDIO_FILE(php_file *)
>
>int PHP_FILE_GET_SOCKETD(php_file *)
>
>
>
>[the names could be PHPFILEGETSTDIOFILE, but thats a different thread... ;-)]
>
>
>
>These could be implemented as macros, provided that all stdio based 
>abstractions "descend" from a common structure where the FILE * lives at 
>the same structure offset, and likewise for the socketd versions.  In the 
>common case, there will only be one of each of these types anyway.
>
>
>
>I don't think that any of this will have a special impact on win32 
>platforms (any more than unix), because we are too high level for that.
>
>
>
>The only real problem is cleaning up the code to use the php_file 
>abstraction instead of assuming it's getting a stdio fp back.
>
>
>
>Once all this is done, the SSL code could be written as an fopen wrapper.
>
>
>
>I'm getting tired, so I may have overlooked something glaringly obvious; 
>please let me know if
>
>I have, or if you have any other suggestions or improvements.
>
>
>
>--Wez.


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] SSL -> joining sockets and files (resent)

[Andi Gutmans]

At 11:29 PM 2/28/2001 +, Wez Furlong wrote:
>On 2001-02-28 20:51:18, Andi Gutmans <[EMAIL PROTECTED]> wrote:
> > Doing some C OOP here would probably come in handy. Short incomplete 
> example:
> > typedef union _io_abstraction {
> >  io_base base;
> >  socket_abstraction socket;
> >  ssl_abstraction ssl;
> >  file_abstraction file;
> > } io_abstraction;
>
>Thats the idea.  However, doing it exactly this way doesn't lend itself to
>having extensions in modules, but that a technicality easily solved by just
>passing pointers to io_base's around, rather than declaring the union.


Yeah you will usually pass around a pointer to io_base so you don't need a 
union. You only need the union if you ever want to save the struct but I 
guess that will usually not be the case.


>The code might still need to check the type of the underlying io, so we
>should probably put an id field into the io base and define bit fields
>to indicate if it can have socket operations performed on it, or if it
>can be fseek'd for example.  Either that or define those operations as
>methods in the io_base.  It feels like we are implementing a VFS layer
>in user space ;-)


Yes, we might have some places which will allow certain io structs and not 
others. In this case we will need to put an ID on each one of them. 
However, the per-struct functions will not need to know the type as they 
will know from the context who they are and cast accordingly.

Andi


> > I wrote this very quickly so I'm not quite sure I got it all right but it
> > could be the general direction. Don't bash me but MS does some nice stuff
> > this way too :)
>
>I believe you - although it is rare to see some "nice" MS code !
>
> > > > I'm going to look into it in more depth and come back with more info
> > > > about where we are using this stuff and where we check for sockets,
> > > > and think some more about the open/connect/construct part of it.
>
>I'm really going to do this now.
>
>--Wez.
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>To contact the list administrators, e-mail: [EMAIL PROTECTED]


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] SSL -> joining sockets and files

[Wez Furlong]

I've just looked through the code.

The current issock stuff is a bit of a nightmare, but not too much of a problem.

Most of the codebase seems to be fairly well behaved with FP_FGETS and friends (apart 
from the interbase extension, where it does the same thing as FP_FREAD without using 
FP_FREAD).

The aim is to reduce three parameters to a single parameter for the FP_ family of 
macros.
Ideally, it would be nice to do this for php_fopen_wrapper as well, and have it return 
the "php_file" abstraction we are proposing.  I'm not sure how well people will like 
this
in general, but thats why I'm talking about it and not changing the code right now.

Whenever an extension needs to open a file it also needs to complain if it can't open 
it.
All over the code we have the same checks to see if it is a socket or a file, if it 
was opened, and if if wasn't complain, but first strip out a password from the 
filename/url etc. etc.

A suggestion is this:

typedef struct _php_file {
 int file_type; /* bitfield: PHP_FILE_STDIO, PHP_FILE_SOCKET */
 int (*write)(php_file *this_ptr, );
 int (*read)(php_file *this_ptr,);
 int (*open)(php_file *this_ptr,);
 int (*close)(php_file *this_ptr,.);
 int (*seek)(php_file * this_ptr, ...); /* useful */
} php_file;

php_file * php_fopen_wrapper(char * filename, char * mode,
 int options,
 char ** opened_path,
 int report_error
 );

Basically the same as the current implementation except that it returns an abstraction 
rather than a bunch of alternatives.
The report error flag will cause the fopen wrapper to display the error message using 
the current active function name from the scripting engine, saving a few lines of code 
for each call where error reporting is required, and increasing maintainability.

This is going to break code in 11 files, but that is relatively easy to fix.

Some code requires that we get a FILE * back (the fopen_wrapper_for_zend is one), and 
some requires a socket (the code in fsock.c), so we need a way to get those out of the 
php_file:

FILE * PHP_FILE_GET_STDIO_FILE(php_file *)
int PHP_FILE_GET_SOCKETD(php_file *)

[the names could be PHPFILEGETSTDIOFILE, but thats a different thread... ;-)]

These could be implemented as macros, provided that all stdio based abstractions 
"descend" from a common structure where the FILE * lives at the same structure offset, 
and likewise for the socketd versions.  In the common case, there will only be one of 
each of these types anyway.

I don't think that any of this will have a special impact on win32 platforms (any more 
than unix), because we are too high level for that.

The only real problem is cleaning up the code to use the php_file abstraction instead 
of assuming it's getting a stdio fp back.

Once all this is done, the SSL code could be written as an fopen wrapper.

I'm getting tired, so I may have overlooked something glaringly obvious; please let me 
know if
I have, or if you have any other suggestions or improvements.

--Wez.


--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] SSL -> joining sockets and files (resent)

[Wez Furlong]

On 2001-02-28 20:51:18, Andi Gutmans <[EMAIL PROTECTED]> wrote:
> Doing some C OOP here would probably come in handy. Short incomplete example:
> typedef union _io_abstraction {
>  io_base base;
>  socket_abstraction socket;
>  ssl_abstraction ssl;
>  file_abstraction file;
> } io_abstraction;

Thats the idea.  However, doing it exactly this way doesn't lend itself to
having extensions in modules, but that a technicality easily solved by just
passing pointers to io_base's around, rather than declaring the union.

The code might still need to check the type of the underlying io, so we
should probably put an id field into the io base and define bit fields
to indicate if it can have socket operations performed on it, or if it
can be fseek'd for example.  Either that or define those operations as
methods in the io_base.  It feels like we are implementing a VFS layer
in user space ;-)

> I wrote this very quickly so I'm not quite sure I got it all right but it 
> could be the general direction. Don't bash me but MS does some nice stuff 
> this way too :)

I believe you - although it is rare to see some "nice" MS code !
 
> > > I'm going to look into it in more depth and come back with more info
> > > about where we are using this stuff and where we check for sockets,
> > > and think some more about the open/connect/construct part of it.

I'm really going to do this now.

--Wez.


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] SSL -> joining sockets and files (resent)

[Andi Gutmans]

Doing some C OOP here would probably come in handy. Short incomplete example:
typedef struct _io_base {
 int (*write)(io_base *this_ptr, );
 int (*read)(io_base *this_ptr,);
 int (*open)(io_base *this_ptr,);
 int (*close)(io_base *this_ptr,.);
} io_base;

typedef struct _stdio_abstraction {
 int (*write)(io_base *this_ptr,);
 int (*read)(io_base *this_ptr,);
 int (*open)(io_base *this_ptr,);
 int (*close)(io_base *this_ptr,.);
 FILE *fp;
} stdio_abstraction;

typedef struct _socket_abstraction {
 int (*write)(io_base *this_ptr,);
 int (*read)(io_base *this_ptr,);
 int (*open)(io_base *this_ptr,);
 int (*close)(io_base *this_ptr,.);
 int socket;
} socket_abstraction;

typedef struct _ssl_abstraction {
 int (*write)();
 int (*read)();
 int (*open)();
 int (*close)(.);
 MySSLStruct ssl;
} ssl_abstraction;

typedef union _io_abstraction {
 io_base base;
 socket_abstraction socket;
 ssl_abstraction ssl;
 file_abstraction file;
} io_abstraction;

Then something like:

socket_abstraction s;
io_abstraction *foo = &s;

foo->write(foo, "blahblah");

and socket_abstraction.write() would of course cast the io_base it receives 
as first argument to socket_abstraction and access it's socket descriptor.

I wrote this very quickly so I'm not quite sure I got it all right but it 
could be the general direction. Don't bash me but MS does some nice stuff 
this way too :)

Andi


At 08:03 PM 2/28/2001 +0100, Stig Venaas wrote:
>On Wed, Feb 28, 2001 at 05:12:55PM +, Wez Furlong wrote:
> > I think what we need depends on how far we are willing to go to make
> > the codebase nicer.  Andi Gutmans suggested that it would be nice
> > to nuke all the checks for sockets in the code; depending on how far
> > we go towards that ideal, we might need to approach this in a different
> > way.
>
>Yes, and I think it's a good idea.
> >
> > The problem we have is that file handles in php can be regular files
> > or sockets, but we have to use either stdio FILEs or unix/posix sockets
> > to represent them, and the php code has to take special steps whenever
> > it needs to write to a file.
> >
> > This causes a conflict in the case of SSL enabled sockets because the
> > thing that is passed back is neither a socket nor a FILE, but does
> > have an underlying socket, hence the "cookie" and socketd parameters/
> > returns from the abstraction.
> >
> > If we expand the abstraction to cover regular files as well as sockets,
> > would it be worth it?
>
>I don't think it's that hard, but I haven't really thought it through.
>What you called sockbuf could contain both socket and file stuff by
>either put it all together in one large structure, or use union or a
>pointer to either a file or a socket structure.
>
>Basically you could have something like:
>
>php_iobuf {
> struct php_io_ops * ops;
> void * cookie;
>};
>
>where cookie can be a pointer to file or socket structure or something
>else. The code can do say ops->write(cookie, data) for both files and
>sockets. You have different write functions for files, normal tcp,
>SSL etc, and the cookie points to php_filebuf, php_sockbuf or what-
>ever is needed for that type. The write function for files is declared
>like say write(struct * php_filebuf, char *data). I think it might be
>enough to have php_io_ops contain read(), write() and close() but I'm
>not sure. If you do all this you can have very different code and data
>for files, sockets, SSL etc. while the code that uses them simply
>passes around a pointer to a php_iobuf structure (that is set up when
>file is opened or socket is created (and possibly connected etc.), and
>calls the write/read/close functions with the cookie.
>
>I could try to describe it more carefully, but I think you understand
>my point.
>
> > I'm going to look into it in more depth and come back with more info
> > about where we are using this stuff and where we check for sockets,
> > and think some more about the open/connect/construct part of it.
>
>Great,
>
>Stig
>
>--
>PHP Development Mailing List 
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>To contact the list administrators, e-mail: [EMAIL PROTECTED]


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] SSL -> joining sockets and files (resent)

[Stig Venaas]

On Wed, Feb 28, 2001 at 05:12:55PM +, Wez Furlong wrote:
> I think what we need depends on how far we are willing to go to make
> the codebase nicer.  Andi Gutmans suggested that it would be nice
> to nuke all the checks for sockets in the code; depending on how far
> we go towards that ideal, we might need to approach this in a different
> way.

Yes, and I think it's a good idea.
> 
> The problem we have is that file handles in php can be regular files
> or sockets, but we have to use either stdio FILEs or unix/posix sockets
> to represent them, and the php code has to take special steps whenever
> it needs to write to a file.
> 
> This causes a conflict in the case of SSL enabled sockets because the
> thing that is passed back is neither a socket nor a FILE, but does
> have an underlying socket, hence the "cookie" and socketd parameters/
> returns from the abstraction.
> 
> If we expand the abstraction to cover regular files as well as sockets,
> would it be worth it?

I don't think it's that hard, but I haven't really thought it through.
What you called sockbuf could contain both socket and file stuff by
either put it all together in one large structure, or use union or a
pointer to either a file or a socket structure.

Basically you could have something like:

php_iobuf {
struct php_io_ops * ops;
void * cookie;
};

where cookie can be a pointer to file or socket structure or something
else. The code can do say ops->write(cookie, data) for both files and
sockets. You have different write functions for files, normal tcp,
SSL etc, and the cookie points to php_filebuf, php_sockbuf or what-
ever is needed for that type. The write function for files is declared
like say write(struct * php_filebuf, char *data). I think it might be
enough to have php_io_ops contain read(), write() and close() but I'm
not sure. If you do all this you can have very different code and data
for files, sockets, SSL etc. while the code that uses them simply
passes around a pointer to a php_iobuf structure (that is set up when
file is opened or socket is created (and possibly connected etc.), and
calls the write/read/close functions with the cookie.

I could try to describe it more carefully, but I think you understand
my point.

> I'm going to look into it in more depth and come back with more info
> about where we are using this stuff and where we check for sockets,
> and think some more about the open/connect/construct part of it.

Great,

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] SSL -> joining sockets and files (resent)

[Wez Furlong]

Sorry - I've been having problems with my mail client;
I have resent the message with sensible line breaks.

On 2001-02-27 06:53:05, Stig Venaas  wrote:
> 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

I must have missed hostconnect().  I Don't know how - I certainly remember
you talking about a long time ago.
 
> 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.

I was just thinking in terms of modularity; it would mean that someone
could provide support for their own weird and wonderful network transport
without having to touch the core code in fsock.c.

> For SSL it should be possible to connect() as usual using
> hostconnect() and then do the SSL negotiation, right?

Yes.
 
> 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.

Yes, I was thinking along those lines too.

I think what we need depends on how far we are willing to go to make
the codebase nicer.  Andi Gutmans suggested that it would be nice
to nuke all the checks for sockets in the code; depending on how far
we go towards that ideal, we might need to approach this in a different
way.

The problem we have is that file handles in php can be regular files
or sockets, but we have to use either stdio FILEs or unix/posix sockets
to represent them, and the php code has to take special steps whenever
it needs to write to a file.

This causes a conflict in the case of SSL enabled sockets because the
thing that is passed back is neither a socket nor a FILE, but does
have an underlying socket, hence the "cookie" and socketd parameters/
returns from the abstraction.

If we expand the abstraction to cover regular files as well as sockets,
would it be worth it?

I'm going to look into it in more depth and come back with more info
about where we are using this stuff and where we check for sockets,
and think some more about the open/connect/construct part of it.

 
--Wez.



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] SSL -> joining sockets and files ?

[Wez Furlong]

On 2001-02-27 06:53:05, Stig Venaas  wrote:
> 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

I must have missed hostconnect().  I Don't know how - I certainly remember
you talking about a long time ago.
 
> 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.

I was just thinking in terms of modularity; it would mean that someone
could provide support for their own weird and wonderful network transport
without having to touch the core code in fsock.c.

> For SSL it should be possible to connect() as usual using
> hostconnect() and then do the SSL negotiation, right?

Yes.
 
> 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.

Yes, I was thinking along those lines too.

I think what we need depends on how far we are willing to go to make
the codebase nicer.  Andi Gutmans suggested that it would be nice
to nuke all the checks for sockets in the code; depending on how far
we go towards that ideal, we might need to approach this in a different
way.

The problem we have is that file handles in php can be regular files
or sockets, but we have to use either stdio FILEs or unix/posix sockets
to represent them, and the php code has to take special steps whenever
it needs to write to a file.

This causes a conflict in the case of SSL enabled sockets because the
thing that is passed back is neither a socket nor a FILE, but does
have an underlying socket, hence the "cookie" and socketd parameters/
returns from the abstraction.

If we expand the abstraction to cover regular files as well as sockets,
would it be worth it?

I'm going to look into it in more depth and come back with more info
about where we are using this stuff and where we check for sockets,
and think some more about the open/connect/construct part of it.

 
--Wez.