RE: [PHP-DEV] sockets extension
And exactly how long is it expected to continue to stay EXPERIMENTAL ? --Roshan -Original Message- From: Wez Furlong [mailto:[EMAIL PROTECTED]] Sent: Friday, September 06, 2002 3:31 PM To: Brian Lalor Cc: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] sockets extension Which part of EXPERIMENTAL in the docs at http://www.php.net/manual/en/function.socket-select.php don't you understand? If you're so desparate to have things cemented, write a patch, post it here and we'll commit it. If you don't have the skills, you might consider offering those that do some positive incentive to do it for you. --Wez. On 09/06/02, Brian Lalor [EMAIL PROTECTED] wrote: Do the maintainers of the PHP sockets extension ever intend to get their act together and cement the API, or are people who need this functionality going to be forced to rewrite their code everytime there's a new point-release of PHP? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] sockets extension
On Mon, 9 Sep 2002, NAIK,ROSHAN (HP-Cupertino,ex1) wrote: And exactly how long is it expected to continue to stay EXPERIMENTAL ? Between 15 days and 15 months. Derick --- Did I help you? http://www.derickrethans.nl/link.php?url=giftlist Frequent ranting: http://www.derickrethans.nl/ --- PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Script Running Machine - www.vl-srm.net --- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] sockets extension
Between 15 days and 15 months. Looking at the CVS its been 19 months since the EXPERMENTAL file was last modified for sockets. No offense intended but, sometimes people dont seem to like to be asked such obvious questions by users. I realize that people in open source are not working for money but this attitude may be a little extreme. The obvious meaning behind the question was is this piece under active development?. Users like to know such things so that they can have reasonable expectations from what they are using or make alternate plans. And this list is the most reasonable place for asking something like that. Bundling functionality into the distribution and tagging them as experimental...its a way of giving end users hope to see something concrete sooner or later...so why flame over it when the user comes back asking how it is doing ? --Roshan -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] sockets extension
Because the user can see how active such functionality is by looking at the CVS logs, and doing a search on php-dev conversations. While the authors have decided to mark it experimental doesn't mean it will ever not be experimental. Not to continue a flame war, but this is Open Source, and it is done on free time. Because you the user feels you'd like to use such functionality it's not typically a concern for the developers. Often times this functionality is added to make their own lives easier, or to try an experiment with something. Take a look at the iD software policy: it'll be ready when it's ready. Thats all there is to it :) On Mon, 9 Sep 2002, NAIK,ROSHAN (HP-Cupertino,ex1) wrote: Between 15 days and 15 months. Looking at the CVS its been 19 months since the EXPERMENTAL file was last modified for sockets. No offense intended but, sometimes people dont seem to like to be asked such obvious questions by users. I realize that people in open source are not working for money but this attitude may be a little extreme. The obvious meaning behind the question was is this piece under active development?. Users like to know such things so that they can have reasonable expectations from what they are using or make alternate plans. And this list is the most reasonable place for asking something like that. Bundling functionality into the distribution and tagging them as experimental...its a way of giving end users hope to see something concrete sooner or later...so why flame over it when the user comes back asking how it is doing ? --Roshan --- Dan KalowskyI'll walk a thousand miles just http://www.deadmime.org/~dankto slip this skin. [EMAIL PROTECTED]- Streets of Philadelphia, [EMAIL PROTECTED]Bruce Springstreen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] sockets extension
Sure (as i did reckon most of what you said in my email) but i dont think there is anything wrong in any user coming out and asking the community what their intentions are going forward. CVS only reflects the situation so far. For example: In our case we deliver PHP as part of our free HP Apache distribution and we get requests from end users asking for so and so PHP extension. It is natural for us (or anybody like us) to come back to this mailing list and ask similar questions to get an idea of where things may be headed. Perhaps it might be nicer to reckon the CURRENT absence of any active development/plans by the ones in the know, rather than flaming over it and giving out bogus estimates to users casually inquiring about it. After all, most of us users (hopefully) realize that there is only finite amount of work that can be done by developers in their free time. As a suggestion : It may be a good idea to reconsider the bundling (and continued bundling in the future) of extensions that are unlikely to get out of expermimental stage due to lack developer activity and/or interest for such extended periods. Else such questions and flame replies simply become more common and benefit no one. --Roshan -Original Message- From: Dan Kalowsky [mailto:[EMAIL PROTECTED]] Sent: Monday, September 09, 2002 2:49 PM To: NAIK,ROSHAN (HP-Cupertino,ex1) Cc: [EMAIL PROTECTED] Subject: RE: [PHP-DEV] sockets extension Because the user can see how active such functionality is by looking at the CVS logs, and doing a search on php-dev conversations. While the authors have decided to mark it experimental doesn't mean it will ever not be experimental. Not to continue a flame war, but this is Open Source, and it is done on free time. Because you the user feels you'd like to use such functionality it's not typically a concern for the developers. Often times this functionality is added to make their own lives easier, or to try an experiment with something. Take a look at the iD software policy: it'll be ready when it's ready. Thats all there is to it :) On Mon, 9 Sep 2002, NAIK,ROSHAN (HP-Cupertino,ex1) wrote: Between 15 days and 15 months. Looking at the CVS its been 19 months since the EXPERMENTAL file was last modified for sockets. No offense intended but, sometimes people dont seem to like to be asked such obvious questions by users. I realize that people in open source are not working for money but this attitude may be a little extreme. The obvious meaning behind the question was is this piece under active development?. Users like to know such things so that they can have reasonable expectations from what they are using or make alternate plans. And this list is the most reasonable place for asking something like that. Bundling functionality into the distribution and tagging them as experimental...its a way of giving end users hope to see something concrete sooner or later...so why flame over it when the user comes back asking how it is doing ? --Roshan --- Dan Kalowsky I'll walk a thousand miles just http://www.deadmime.org/~dank to slip this skin. [EMAIL PROTECTED] - Streets of Philadelphia, [EMAIL PROTECTED] Bruce Springstreen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] sockets extension
Dan Kalowsky writes: Not to continue a flame war, but this is Open Source, and it is done on free time. Open Source is a philosophy. It shouldn't be an excuse. Nothing prevents us from treating people with patience and courtesy. Except of course bad manners and bad attitude. Because you the user feels you'd like to use such functionality it's not typically a concern for the developers. Often times this functionality is added to make their own lives easier, or to try an experiment with something. Take a look at the iD software policy: it'll be ready when it's ready. Thats all there is to it :) Like so. Regards Mike Robinson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] sockets extension...pecl it
Dan Kalowsky wrote: Because the user can see how active such functionality is by looking at the CVS logs, and doing a search on php-dev conversations. Sorry, but that's a copout. It expects way to much of the user. If it's going to remain experimental, OR the api is going to continue to change in incompatible ways, it shouldn't be part of the standard PHP distribution. We have a means to distribute extensions outside of PHP now, IMO experimental extensions should not be allowed into the core PHP distribuation any longer. PECL it. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] sockets extension...pecl it
This extension does not belongs in PECL. It is fully platform compatible, all other languages offer this functionality, it is actively maintained (by me), and it will be marked stable by version 4.3 -Jason n Mon, 2002-09-09 at 18:13, Shane Caraveo wrote: Dan Kalowsky wrote: Because the user can see how active such functionality is by looking at the CVS logs, and doing a search on php-dev conversations. Sorry, but that's a copout. It expects way to much of the user. If it's going to remain experimental, OR the api is going to continue to change in incompatible ways, it shouldn't be part of the standard PHP distribution. We have a means to distribute extensions outside of PHP now, IMO experimental extensions should not be allowed into the core PHP distribuation any longer. PECL it. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] sockets extension
Which part of EXPERIMENTAL in the docs at http://www.php.net/manual/en/function.socket-select.php don't you understand? If you're so desparate to have things cemented, write a patch, post it here and we'll commit it. If you don't have the skills, you might consider offering those that do some positive incentive to do it for you. --Wez. On 09/06/02, Brian Lalor [EMAIL PROTECTED] wrote: Do the maintainers of the PHP sockets extension ever intend to get their act together and cement the API, or are people who need this functionality going to be forced to rewrite their code everytime there's a new point-release of PHP? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] sockets
On Sun, 2002-04-28 at 22:43, Jason Greene wrote: In the case of a socket you are selecting on has errored, the socket will show up as readable. You then can perform a socket_read/recv, and you should receive NULL (errored socket), then you can call socket_last_error to receive the errno. Unless I'm just a really bad coder and have no idea what I'm doing, this won't help. I tried using socket_last_error, but it returns the same error code whether the socket has no data waiting (remember this is a non-blocking socket) or if the socket has died. I can only tell if it is dead by writing to the socket. What I'd like to do is just find out if the socket is still alive. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] sockets
On Mon, 2002-04-29 at 11:14, Steve Meyers wrote: On Sun, 2002-04-28 at 22:43, Jason Greene wrote: In the case of a socket you are selecting on has errored, the socket will show up as readable. You then can perform a socket_read/recv, and you should receive NULL (errored socket), then you can call socket_last_error to receive the errno. Unless I'm just a really bad coder and have no idea what I'm doing, this won't help. I tried using socket_last_error, but it returns the same error code whether the socket has no data waiting (remember this is a non-blocking socket) or if the socket has died. I can only tell if it is dead by writing to the socket. What I'd like to do is just find out if the socket is still alive. You have to call read/recv or write/send before you call last_error. You should get FALSE from the return of your read/recv, and socket_last_error should contain EAGAIN if no data is avail on a non-blocking socket, ECONRESET if the connection was reset by the peer(etc..etc..), or you would get from the return of the read (0 bytes from recv) which would indicate EOF. -Jason -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] sockets
You can kind of simulate multithreading with the sockets extension by using socket_select(). Technically, the result is multiplexing and not multithreading, but in the end, it works quite nicely -- you can handle multiple incoming/outgoing connections without the need for forking or multiple threads. Handling multiple sockets is definitely do-able in PHP, and it's relatively easy to set up. There should be an example I wrote somewhere in the archives. J Dan Hardiker wrote: The only feature which would be useful towards this module is threading. If PHP were able to thread it could handle multiple incoming sockets and neglegate the need for IPC between child processes (where PCNTL has been used) as it could all be handled by a common parent with shared (not copied) variables. Just my 2p's worth -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] sockets
One way to find which socket has died, if any, is to loop through each socket in the three sets (read/write/exceptions) and do a select() on each one to see if you can read with a timeout of 0. (The bad one being the one where select() returns -1, I think.) J Steve Meyers wrote: There's only one thing it's missing -- the equivalent of socket_get_status(), which is not part of the extension, despite the name. If I set my socket to nonblocking, the only way to tell if it has died is to try to write to it, which isn't always a desirable thing to do :) Unless there's another way that I just don't understand. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] sockets
I was hoping on tagging this extension as stable by the next PHP release. In order to do this, everyone needs to feel comfortable with the extension. Thanks, -Jason On Thu, 2002-04-25 at 12:46, Michael Virnstein wrote: Hi, as i could read in the manual, the socket functions are completely experimental. When do you think the API gets final and won't change anymore. Any comments on this are welcome. Michael -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] sockets
On Sun, 2002-04-28 at 18:31, J Smith wrote: One way to find which socket has died, if any, is to loop through each socket in the three sets (read/write/exceptions) and do a select() on each one to see if you can read with a timeout of 0. (The bad one being the one where select() returns -1, I think.) J socket_select returns NULL on error. -Jason Steve Meyers wrote: There's only one thing it's missing -- the equivalent of socket_get_status(), which is not part of the extension, despite the name. If I set my socket to nonblocking, the only way to tell if it has died is to try to write to it, which isn't always a desirable thing to do :) Unless there's another way that I just don't understand. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] sockets
True, Threading support would be a powerful feature to php, but it is not likely to happen anytime soon, due to current design issues with doing it, and the fact that it would take someone who was really really focused on adding this functionality (it would be alot of work). Now with that said, you should be able to handle everything you need to do with I/O multiplexing, or prefork. If you absolutely need the performance of threads, and your task is complex enough, you may want to look at building a simple multi-threaded c client lib, and then building a php wrapper over it. Also, php has a little known functionality called ticks that allows you to have an external function called between X number of opcodes. Hope this helps, -Jason On Fri, 2002-04-26 at 11:05, Dan Hardiker wrote: The only feature which would be useful towards this module is threading. If PHP were able to thread it could handle multiple incoming sockets and neglegate the need for IPC between child processes (where PCNTL has been used) as it could all be handled by a common parent with shared (not copied) variables. Just my 2p's worth -- Dan Hardiker [[EMAIL PROTECTED]] ADAM Software Systems Engineer First Creative Ltd I've been using it since the first API revision and it's been working fine for me. (Up to and including the latest API revision.) As far as I'm concerned, it's getting pretty close to losing the experimental tag. (Perhaps by PHP 4.3.x or so, barring any glarring problems that I've not encountered.) J Markus Fischer wrote: Hi, Simple when enough people have tested it and it reaches the consensus that it's mature enough for being called stable (api doesn't change anymore, more testers, you name it). - Markus On Thu, Apr 25, 2002 at 07:46:30PM +0200, Michael Virnstein wrote : Hi, as i could read in the manual, the socket functions are completely experimental. When do you think the API gets final and won't change anymore. Any comments on this are welcome. Michael -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] sockets
Actually, I just reread your response again. socket_select returns NULL on a SELECT error, this does not mean that it will return an error on a socket IN the set you are selecting on that has errored. In the case of a socket you are selecting on has errored, the socket will show up as readable. You then can perform a socket_read/recv, and you should receive NULL (errored socket), then you can call socket_last_error to receive the errno. If the socket has hit an eof your socket_read would have returned a 0 len string, socket_recv would return 0 bytes, and socket_select would have shown the socket to be readable. All in all, socket_get_status is designed for the abstracted interface fsockopen, and not for the lowlevel socket. The way it does this is by performing the steps suggested by J. Smith and myself above. Also, if you want to just check for an error on a socket, and you don't want to read your data (which you should rarely have to do) there is a MSG_PEEK option you can pass socket_recv that will allow you to look ahead and not clear. Thanks, -Jason Sun, 2002-04-28 at 22:56, Jason Greene wrote: On Sun, 2002-04-28 at 18:31, J Smith wrote: One way to find which socket has died, if any, is to loop through each socket in the three sets (read/write/exceptions) and do a select() on each one to see if you can read with a timeout of 0. (The bad one being the one where select() returns -1, I think.) J socket_select returns NULL on error. -Jason Steve Meyers wrote: There's only one thing it's missing -- the equivalent of socket_get_status(), which is not part of the extension, despite the name. If I set my socket to nonblocking, the only way to tell if it has died is to try to write to it, which isn't always a desirable thing to do :) Unless there's another way that I just don't understand. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] sockets
I've been using it since the first API revision and it's been working fine for me. (Up to and including the latest API revision.) As far as I'm concerned, it's getting pretty close to losing the experimental tag. (Perhaps by PHP 4.3.x or so, barring any glarring problems that I've not encountered.) J Markus Fischer wrote: Hi, Simple when enough people have tested it and it reaches the consensus that it's mature enough for being called stable (api doesn't change anymore, more testers, you name it). - Markus On Thu, Apr 25, 2002 at 07:46:30PM +0200, Michael Virnstein wrote : Hi, as i could read in the manual, the socket functions are completely experimental. When do you think the API gets final and won't change anymore. Any comments on this are welcome. Michael -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] sockets
The only feature which would be useful towards this module is threading. If PHP were able to thread it could handle multiple incoming sockets and neglegate the need for IPC between child processes (where PCNTL has been used) as it could all be handled by a common parent with shared (not copied) variables. Just my 2p's worth -- Dan Hardiker [[EMAIL PROTECTED]] ADAM Software Systems Engineer First Creative Ltd I've been using it since the first API revision and it's been working fine for me. (Up to and including the latest API revision.) As far as I'm concerned, it's getting pretty close to losing the experimental tag. (Perhaps by PHP 4.3.x or so, barring any glarring problems that I've not encountered.) J Markus Fischer wrote: Hi, Simple when enough people have tested it and it reaches the consensus that it's mature enough for being called stable (api doesn't change anymore, more testers, you name it). - Markus On Thu, Apr 25, 2002 at 07:46:30PM +0200, Michael Virnstein wrote : Hi, as i could read in the manual, the socket functions are completely experimental. When do you think the API gets final and won't change anymore. Any comments on this are welcome. Michael -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] sockets
There's only one thing it's missing -- the equivalent of socket_get_status(), which is not part of the extension, despite the name. If I set my socket to nonblocking, the only way to tell if it has died is to try to write to it, which isn't always a desirable thing to do :) Unless there's another way that I just don't understand. J Smith wrote: I've been using it since the first API revision and it's been working fine for me. (Up to and including the latest API revision.) As far as I'm concerned, it's getting pretty close to losing the experimental tag. (Perhaps by PHP 4.3.x or so, barring any glarring problems that I've not encountered.) J Markus Fischer wrote: Hi, Simple when enough people have tested it and it reaches the consensus that it's mature enough for being called stable (api doesn't change anymore, more testers, you name it). - Markus On Thu, Apr 25, 2002 at 07:46:30PM +0200, Michael Virnstein wrote : Hi, as i could read in the manual, the socket functions are completely experimental. When do you think the API gets final and won't change anymore. Any comments on this are welcome. Michael -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Sockets Question
Eric Liedtke wrote: I'm new in town here, so to speak, so I'm not sure about proper protocol here, but I found,what I feel is a problem in the socket extension code. Specifically in the socket_bind function. I was working with a friends code and it was trying to bind to port 80, however when I would check with sockstat it was showing the process bound to a random port. So I started poking around and found that if the addr argument, (which by the way defaults to 0 in the code I was working with) wasn't a valid name the bind function was set to fail because the gethostbyname test would fail. I would propose that if the sock_family is AF_INET the addr arg should be a valid ip address and that a gethostbyname function be made available to do name to ip conversion if a user needs it. We already know we are binding an AF_INET family socket by the case statement so all we should need to do is fill in the address and the AF_INET into the sockaddr. I'd be happy to provide an implementation, but wanted to see others opinions before I did anything. Eric Liedtke -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Sockets Question
Oops forgot the message body on the last one Ok so after sleeping on it I don't think my solution was totally in line with the beauty and simplicity of php, I expect you should be able to pass either a hostname or a valid ip in the addr arg. Anyway the other part that confused me is that in the case of the gethostbyname failure I would have thought that the inability to bind and the PHP_SOCKET_ERROR and return FALSE should have killed the sript, but somehow the script continued and what's more confusing is that the system still manaed to bind a random port? I'll through it some more.. -e Eric Liedtke wrote: I'm new in town here, so to speak, so I'm not sure about proper protocol here, but I found,what I feel is a problem in the socket extension code. Specifically in the socket_bind function. I was working with a friends code and it was trying to bind to port 80, however when I would check with sockstat it was showing the process bound to a random port. So I started poking around and found that if the addr argument, (which by the way defaults to 0 in the code I was working with) wasn't a valid name the bind function was set to fail because the gethostbyname test would fail. I would propose that if the sock_family is AF_INET the addr arg should be a valid ip address and that a gethostbyname function be made available to do name to ip conversion if a user needs it. We already know we are binding an AF_INET family socket by the case statement so all we should need to do is fill in the address and the AF_INET into the sockaddr. I'd be happy to provide an implementation, but wanted to see others opinions before I did anything. Eric Liedtke -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Sockets Question
Uhhh nevermind. I just grabbed 4.2.0RC2 and found that a slew of fixes have already been commited. -e Eric Liedtke wrote: Oops forgot the message body on the last one Ok so after sleeping on it I don't think my solution was totally in line with the beauty and simplicity of php, I expect you should be able to pass either a hostname or a valid ip in the addr arg. Anyway the other part that confused me is that in the case of the gethostbyname failure I would have thought that the inability to bind and the PHP_SOCKET_ERROR and return FALSE should have killed the sript, but somehow the script continued and what's more confusing is that the system still manaed to bind a random port? I'll through it some more.. -e Eric Liedtke wrote: I'm new in town here, so to speak, so I'm not sure about proper protocol here, but I found,what I feel is a problem in the socket extension code. Specifically in the socket_bind function. I was working with a friends code and it was trying to bind to port 80, however when I would check with sockstat it was showing the process bound to a random port. So I started poking around and found that if the addr argument, (which by the way defaults to 0 in the code I was working with) wasn't a valid name the bind function was set to fail because the gethostbyname test would fail. I would propose that if the sock_family is AF_INET the addr arg should be a valid ip address and that a gethostbyname function be made available to do name to ip conversion if a user needs it. We already know we are binding an AF_INET family socket by the case statement so all we should need to do is fill in the address and the AF_INET into the sockaddr. I'd be happy to provide an implementation, but wanted to see others opinions before I did anything. Eric Liedtke -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Sockets Extension Rework (API, etc...) VERY LONG
On Thu, 2002-02-21 at 01:40, Derick Rethans wrote: Hey Jason, On 20 Feb 2002, Jason Greene wrote: Instead of just committing a gigantic patch to solve these problems, and redefine the extensions behavior, I decided to open a thread for discussion on how I intend to solve all the problems. My solution does involve modifying pieces of the API, which causes BC concerns. I do think about these things, and I really think we should stabilize and finalize this module, as we have already radically changed the API once before. Just fix it so that it is both consistent and that the extension has a clean API. I wouldn't worry about BC here, cause the extension is experimental (with a big message in the manual). Thats what I was hoping : ) Timeline Stabilization = I would like to fix all of this by 4.2.X. I propose that we then mark the extension as stable, and freeze the API. Please send your feedback on your thoughts and concerns on these changes. Sounds all sane to me. Good luck! Great!!, Well provided I don't get any negative feedback on these, I will start right away!!! -Jason Derick - PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED] SRM: Site Resource Manager - www.vl-srm.net - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Sockets Extension Rework (API, etc...) VERY LONG
Hey Jason, On 20 Feb 2002, Jason Greene wrote: Instead of just committing a gigantic patch to solve these problems, and redefine the extensions behavior, I decided to open a thread for discussion on how I intend to solve all the problems. My solution does involve modifying pieces of the API, which causes BC concerns. I do think about these things, and I really think we should stabilize and finalize this module, as we have already radically changed the API once before. Just fix it so that it is both consistent and that the extension has a clean API. I wouldn't worry about BC here, cause the extension is experimental (with a big message in the manual). Timeline Stabilization = I would like to fix all of this by 4.2.X. I propose that we then mark the extension as stable, and freeze the API. Please send your feedback on your thoughts and concerns on these changes. Sounds all sane to me. Good luck! Derick - PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED] SRM: Site Resource Manager - www.vl-srm.net - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] sockets problems patch
On Sun, Dec 09, 2001 at 04:17:57PM -0500, benjamin yates wrote: The problem with the zip file he sent is also that a: ]$ diff -uN orig new produces a unified diff with almost all of it being whitespace related, so its near impossible to view the changes... that's what i did;-) hmmm i think it's more a cr/lf thing... my diff -uN output seems okay to me. i'll convert it back to lf... try the same url... http://www.newnetwork.com/benjamin_sockets.zip now that i changed it. will look at it as soon as i find some time. tc -- 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]
Re: [PHP-DEV] sockets problems patch
please send a unified diff. i'll look at integrating your changes then! tc On Sat, Dec 08, 2001 at 08:20:56PM -0500, benjamin yates wrote: hey all... i've been using the sockets extension pretty extensively for the past couple months, and it has some real problems. obviously the best reason for it is the ability to use non-blocking sockets in php, which is great for writing simple tcpip clients and services. i've done this with a set of state-machines and it works very well. i had to change the code alot though before i could make it all work, because of two issues. first, the library tracks socket errors with 'errno' which isn't proper on win32, where you must use WSAGetLastError() instead. that's a simple fix... the second has more changes. currently, the library stores the last error only when socket calls return error-ish values. which is a problem because the return value of the sockets calls is not what is returned to the php script. this doesn't provide enough data for writing an app that uses non-blocking sockets. example... socket_read() returns false if it didn't read anything. recv() returns the number of bytes read OR zero of the connection was closed OR -1 if another error is in errno/WSAGetLastError. since socket_read only returns good or bad, you can't tell the specific error without the socket_last_error being correct... i hope this makes sense to someone. the last time i built this and patched it, i sent my changes from (at the time) the current CVS to the authors in the sockets.c but never got any response - so now i'm posting it here. i repatched the latest cvs snapshot, and i just tested it out on one of my scripts and it's working fine for me. i don't know if it might break some unix implementations - i think it will be fine. the code isn't the best, because there are places where socket function calls are inside of if()'s, and the last error must be stored, so instead of reorganize everything, i just put multiple calls to my error storage macro where it was needed. i don't know all the coding standards you go by so i didnt' want to spend time making a bunch of changes that wouldn't be wanted. i zipped my sockets.c and the original, taken from the latest cvs snapshot - it's available at http://www.newnetwork.com/benjamin_sockets.zip thanks for looking at it... oh and i don't know why someone decided that the socket_last_error() should clear the error when calling it, i can't think of any reason why... and it means that i have to store it before i use it in a script, if i must make multiple references to it. not a big deal but i just can't come up with why it should be cleared. well perhaps someone thought it should be cleared before i decided that it should be set after every call :) -benjamin -- 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] -- 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]
Re: [PHP-DEV] sockets problems patch
please send a unified diff. i'll look at integrating your changes then! The problem with the zip file he sent is also that a: ]$ diff -uN orig new produces a unified diff with almost all of it being whitespace related, so its near impossible to view the changes... -Sterling tc On Sat, Dec 08, 2001 at 08:20:56PM -0500, benjamin yates wrote: hey all... i've been using the sockets extension pretty extensively for the past couple months, and it has some real problems. obviously the best reason for it is the ability to use non-blocking sockets in php, which is great for writing simple tcpip clients and services. i've done this with a set of state-machines and it works very well. i had to change the code alot though before i could make it all work, because of two issues. first, the library tracks socket errors with 'errno' which isn't proper on win32, where you must use WSAGetLastError() instead. that's a simple fix... the second has more changes. currently, the library stores the last error only when socket calls return error-ish values. which is a problem because the return value of the sockets calls is not what is returned to the php script. this doesn't provide enough data for writing an app that uses non-blocking sockets. example... socket_read() returns false if it didn't read anything. recv() returns the number of bytes read OR zero of the connection was closed OR -1 if another error is in errno/WSAGetLastError. since socket_read only returns good or bad, you can't tell the specific error without the socket_last_error being correct... i hope this makes sense to someone. the last time i built this and patched it, i sent my changes from (at the time) the current CVS to the authors in the sockets.c but never got any response - so now i'm posting it here. i repatched the latest cvs snapshot, and i just tested it out on one of my scripts and it's working fine for me. i don't know if it might break some unix implementations - i think it will be fine. the code isn't the best, because there are places where socket function calls are inside of if()'s, and the last error must be stored, so instead of reorganize everything, i just put multiple calls to my error storage macro where it was needed. i don't know all the coding standards you go by so i didnt' want to spend time making a bunch of changes that wouldn't be wanted. i zipped my sockets.c and the original, taken from the latest cvs snapshot - it's available at http://www.newnetwork.com/benjamin_sockets.zip thanks for looking at it... oh and i don't know why someone decided that the socket_last_error() should clear the error when calling it, i can't think of any reason why... and it means that i have to store it before i use it in a script, if i must make multiple references to it. not a big deal but i just can't come up with why it should be cleared. well perhaps someone thought it should be cleared before i decided that it should be set after every call :) -benjamin -- 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] -- 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] -- 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]
Re: [PHP-DEV] sockets problems patch
On Sun, Dec 09, 2001 at 07:42:46PM +0100, Sterling Hughes wrote: please send a unified diff. i'll look at integrating your changes then! The problem with the zip file he sent is also that a: ]$ diff -uN orig new produces a unified diff with almost all of it being whitespace related, so its near impossible to view the changes... that's what i did;-) -Sterling tc On Sat, Dec 08, 2001 at 08:20:56PM -0500, benjamin yates wrote: hey all... i've been using the sockets extension pretty extensively for the past couple months, and it has some real problems. obviously the best reason for it is the ability to use non-blocking sockets in php, which is great for writing simple tcpip clients and services. i've done this with a set of state-machines and it works very well. i had to change the code alot though before i could make it all work, because of two issues. first, the library tracks socket errors with 'errno' which isn't proper on win32, where you must use WSAGetLastError() instead. that's a simple fix... the second has more changes. currently, the library stores the last error only when socket calls return error-ish values. which is a problem because the return value of the sockets calls is not what is returned to the php script. this doesn't provide enough data for writing an app that uses non-blocking sockets. example... socket_read() returns false if it didn't read anything. recv() returns the number of bytes read OR zero of the connection was closed OR -1 if another error is in errno/WSAGetLastError. since socket_read only returns good or bad, you can't tell the specific error without the socket_last_error being correct... i hope this makes sense to someone. the last time i built this and patched it, i sent my changes from (at the time) the current CVS to the authors in the sockets.c but never got any response - so now i'm posting it here. i repatched the latest cvs snapshot, and i just tested it out on one of my scripts and it's working fine for me. i don't know if it might break some unix implementations - i think it will be fine. the code isn't the best, because there are places where socket function calls are inside of if()'s, and the last error must be stored, so instead of reorganize everything, i just put multiple calls to my error storage macro where it was needed. i don't know all the coding standards you go by so i didnt' want to spend time making a bunch of changes that wouldn't be wanted. i zipped my sockets.c and the original, taken from the latest cvs snapshot - it's available at http://www.newnetwork.com/benjamin_sockets.zip thanks for looking at it... oh and i don't know why someone decided that the socket_last_error() should clear the error when calling it, i can't think of any reason why... and it means that i have to store it before i use it in a script, if i must make multiple references to it. not a big deal but i just can't come up with why it should be cleared. well perhaps someone thought it should be cleared before i decided that it should be set after every call :) -benjamin -- 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] -- 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] -- 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] -- 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]
Re: [PHP-DEV] sockets problems patch
The problem with the zip file he sent is also that a: ]$ diff -uN orig new produces a unified diff with almost all of it being whitespace related, so its near impossible to view the changes... that's what i did;-) hmmm i think it's more a cr/lf thing... my diff -uN output seems okay to me. i'll convert it back to lf... try the same url... http://www.newnetwork.com/benjamin_sockets.zip now that i changed it. if that's not correct, then i'm not sure what to do with it... what is the tab-spacing everyone is using btw? -benjamin -- 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]
Re: [PHP-DEV] sockets issues ?
On Thursday 26 July 2001 18:06, Arnauld Dravet - smurfie wrote:
Then i tried that:
$sock_tab = socket_get_status($sock);
if ($sock_tab[unread_bytes] = 0)
{
$a_lire = true;
while ($a_lire)
{
$bytes_left = $sock_tab[unread_bytes];
print(brReading from the socket: ($bytes_left bytes left in the
socket buffer) br);
$buffer = fgets($sock, 128);
print($buffer);
flush();
$buffer=;
$sock_tab = socket_get_status($sock);
if ($sock_tab[unread_bytes] = 0) $a_lire = false;
missing = here:
if ($sock_tab[unread_bytes] == 0) $a_lire = false;
}
print($bufferbr);
}
else print(brNo informations received on the socket.br);
On the other hand, i've also encountered misc. socket problems in 4.0.6.
--Leo
--
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]
Re: [PHP-DEV] sockets issues ?
Hello Leo,
Thanks for your reply, because i really need that script to be made ...
Okay i made a typo where you noticed it, it should be == not =. (actually it
doesn't really change anything to my problem :( )
What i don't understand is why the first call:
$sock_tab = socket_get_status($sock);
if ($sock_tab[unread_bytes] = 0)
is evaluated to =0 (it enters the loop and try to read the socket)
the funny thing is that all the output made on the web page is:
Reading from the socket: (0 bytes left in the socket buffer) -- why did he
enter the loop if $sock_tab[unread_bytes] == 0 ??
#7#-,Smurfie,18,swordsman,i died in the luggies dungeon near Mayoi, need
corpse recovery,UnAck#7#-,smurfie,18,swordsman,truc -- informations fgets
received via the socket
Reading from the socket: (71 bytes left in the socket buffer) --
socket_get_status detected there are some data on the socket so we
re-entered the loop
bidule,UnAck#7#-,smurfie,18,swordsman,truc bidule,UnAck -- we
receive the 2nd part of the informations which were not complete because of
the 128bytes limited fgets
and there PHP hangs, browser keep waiting for the end of the page ...
what troubles did you have with 4.0.6 and how did you fix it ?
Thanks again
Arnauld
- Original Message -
From: Leo [EMAIL PROTECTED]
To: Arnauld Dravet - smurfie [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Thursday, July 26, 2001 7:06 PM
Subject: Re: [PHP-DEV] sockets issues ?
On Thursday 26 July 2001 18:06, Arnauld Dravet - smurfie wrote:
Then i tried that:
$sock_tab = socket_get_status($sock);
if ($sock_tab[unread_bytes] = 0)
{
$a_lire = true;
while ($a_lire)
{
$bytes_left = $sock_tab[unread_bytes];
print(brReading from the socket: ($bytes_left bytes left in the
socket buffer) br);
$buffer = fgets($sock, 128);
print($buffer);
flush();
$buffer=;
$sock_tab = socket_get_status($sock);
if ($sock_tab[unread_bytes] = 0) $a_lire = false;
missing = here:
if ($sock_tab[unread_bytes] == 0) $a_lire = false;
}
print($bufferbr);
}
else print(brNo informations received on the socket.br);
On the other hand, i've also encountered misc. socket problems in 4.0.6.
--Leo
--
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]
--
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]
Re: [PHP-DEV] Sockets
On Wed, Jul 25, 2001 at 03:20:35PM -0400, colin mcdonald wrote : Are the php socket functions still as experimental as indicated in the manual? They are still experimental and function names/parameter orders is still subject to change. Recently there was also a thread about some possible upcoming changes, just read the archiv. - Markus -- Markus Fischer, http://guru.josefine.at/~mfischer/ EMail: [EMAIL PROTECTED] PGP Public Key: http://guru.josefine.at/~mfischer/C2272BD0.asc PGP Fingerprint: D3B0 DD4F E12B F911 3CE1 C2B5 D674 B445 C227 2BD0 -- 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]
Re: [PHP-DEV] Sockets
On Wed, Jul 25, 2001 at 11:32:24PM +0200, Markus Fischer wrote : On Wed, Jul 25, 2001 at 03:20:35PM -0400, colin mcdonald wrote : Are the php socket functions still as experimental as indicated in the manual? They are still experimental and function names/parameter orders is still subject to change. Recently there was also a thread about some possible upcoming changes, just read the archiv. GOD DAMMIT! and use your fu@#$@# real email address 8=[ - Markus :) -- 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]
Re: [PHP-DEV] sockets extension
Stig Venaas wrote: On Thu, May 17, 2001 at 01:48:06AM -0400, Sterling Hughes wrote: Well, it probably could be done anyway (abstract it another step). However, I don't see it really being that beneficial. The socket functions provide *low level* access to the system socket features. There's no real point in abstracting that (I think it gets a bit to confusing if you do) any further. The only thing I would want, is that the type of the socket is stored in some internal datastructure. That is if the socket is PF_INET, PF_INET6 or PF_LOCAL. The old code and maybe yours, used getsockname() to check the type, but you can't really trust getsockname() to get the appropriate info unless the socket has been bound. I've checked this on a few systems some months ago. that shouldn't be a problem. -Sterling -- 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]
Re: [PHP-DEV] sockets extension
At 21:23 16.05.2001 +0100, Wez Furlong wrote: I'm not sure that the sockets extension would benefit from php_streams as much as php_streams would benefit from the sockets extension, if you see what I mean. I would like to see it using php_streams, as that would result in PHP being much more flexible for the person coding in PHP; they needn't worry about the type of the file handle they pass to any function. To integrate php_streams properly, ext/sockets should converge with fsock.c and use the same underlying sockets implemented as php_streams (it's not too much work). I think it's a good idea to get it done. i had a quick look at it, but i think it can't be done, due to the simple fact that under windows socket descriptors are not file descriptors like under unix. it could work under NT (file I/O is similiar to unix), but not under the 9.x family. (but maybe i'm missing somehing) daniel /*-- daniel beulshausen - [EMAIL PROTECTED] using php on windows? http://www.php4win.de -- 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]
Re: [PHP-DEV] sockets extension
Daniel Beulshausen wrote: At 21:23 16.05.2001 +0100, Wez Furlong wrote: I'm not sure that the sockets extension would benefit from php_streams as much as php_streams would benefit from the sockets extension, if you see what I mean. I would like to see it using php_streams, as that would result in PHP being much more flexible for the person coding in PHP; they needn't worry about the type of the file handle they pass to any function. To integrate php_streams properly, ext/sockets should converge with fsock.c and use the same underlying sockets implemented as php_streams (it's not too much work). I think it's a good idea to get it done. i had a quick look at it, but i think it can't be done, due to the simple fact that under windows socket descriptors are not file descriptors like under unix. it could work under NT (file I/O is similiar to unix), but not under the 9.x family. (but maybe i'm missing somehing) Well, it probably could be done anyway (abstract it another step). However, I don't see it really being that beneficial. The socket functions provide *low level* access to the system socket features. There's no real point in abstracting that (I think it gets a bit to confusing if you do) any further. -Sterling -- 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]
Re: [PHP-DEV] sockets extension
Daniel, Would it make sense to try to integrate the new php_streams into this extension? It might give php_streams a push and I'm sure Wez would work with you fixing any remaining issues. It would be a nice test bed. What do you think? About backwards compatibility, without having read the code it sounds as if you're doing the right thing as opposed to the old module. Do any of the new function names overlap with the old ones? I'm not quite sure how we should tackle backwards compatibility here. Andi At 09:28 PM 5/16/2001 +0200, Daniel Beulshausen wrote: hi, i've updated the sockets extension so that it's usable under win32 as well, however it's incompatible to the old extension for some reasons (thats why i want some feedback): sockets fd under win32 are usigned, the previous approach of returning long's and check for 0 wouldn't have worked, thus it's been converted to use resources (which is also cleaner behaviour IMO). the return values of most functions had to be changed, because win32 has an complete different error handling. as that together would already break old scripts i've also renamed the functions to (hopefully) go with the standards. daniel /*-- daniel beulshausen - [EMAIL PROTECTED] using php on windows? http://www.php4win.de -- 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] -- 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]
Re: [PHP-DEV] sockets extension
At 22:49 16.05.2001 +0300, Andi Gutmans wrote: Daniel, Would it make sense to try to integrate the new php_streams into this extension? It might give php_streams a push and I'm sure Wez would work with you fixing any remaining issues. It would be a nice test bed. What do you think? that surely would be a great idea, just didn't had the time to look at them yet. i'll do that tomorrow :) About backwards compatibility, without having read the code it sounds as if you're doing the right thing as opposed to the old module. Do any of the new function names overlap with the old ones? I'm not quite sure how we should tackle backwards compatibility here. i think the same, but i'm pretty sure that it'll break alot sockets scripts. daniel /*-- daniel beulshausen - [EMAIL PROTECTED] using php on windows? http://www.php4win.de -- 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]
Re: [PHP-DEV] sockets extension
At 04:01 16.05.2001 -0400, Sterling Hughes wrote: I've been meaning for a while to do this, so yes, that's perfectly ok. I don't quite understand the return values of most functions had to be changed because win32 has a completely different error handling. Can you elaborate a bit more. WSAGetlastError() returns completly different errno's, thus i think it's not a good idea to use them as return values (and for the users to rely on them). Also, strerror() is to my knowledge, available on Win32 systems (check out FormatMessage()). *ouch* I WILL NOT DO WINDOWS PROGRAMMING I WILL NOT DO WINDOWS PROGRAMMING ... as that together would already break old scripts i've also renamed the functions to (hopefully) go with the standards. The naming looks pretty good. It seems like most people want this (I don't, but, ah well.) great. daniel /*-- daniel beulshausen - [EMAIL PROTECTED] using php on windows? http://www.php4win.de -- 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]
Re: [PHP-DEV] sockets extension
Daniel Beulshausen wrote: hi, i've updated the sockets extension so that it's usable under win32 as well, however it's incompatible to the old extension for some reasons (thats why i want some feedback): sockets fd under win32 are usigned, the previous approach of returning long's and check for 0 wouldn't have worked, thus it's been converted to use resources (which is also cleaner behaviour IMO). the return values of most functions had to be changed, because win32 has an complete different error handling. I've been meaning for a while to do this, so yes, that's perfectly ok. I don't quite understand the return values of most functions had to be changed because win32 has a completely different error handling. Can you elaborate a bit more. Also, strerror() is to my knowledge, available on Win32 systems (check out FormatMessage()). *ouch* I WILL NOT DO WINDOWS PROGRAMMING I WILL NOT DO WINDOWS PROGRAMMING ... as that together would already break old scripts i've also renamed the functions to (hopefully) go with the standards. The naming looks pretty good. It seems like most people want this (I don't, but, ah well.) Nice Job! -Sterling -- 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]
Re: [PHP-DEV] sockets extension
At 22:49 16.05.2001 +0300, Andi Gutmans wrote: Daniel, Would it make sense to try to integrate the new php_streams into this extension? It might give php_streams a push and I'm sure Wez would work with you fixing any remaining issues. It would be a nice test bed. What do you think? About backwards compatibility, without having read the code it sounds as if you're doing the right thing as opposed to the old module. Do any of the new function names overlap with the old ones? I'm not quite sure how we should tackle backwards compatibility here. forgot to answer that, no the new function names don't overlap, thereprefixed i.e. socket - socket_create fd_dealloc - socket_fd_free create_listen_sock - socket_create_listen ... daniel /*-- daniel beulshausen - [EMAIL PROTECTED] using php on windows? http://www.php4win.de -- 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]
Re: [PHP-DEV] sockets extension
disclaimerI don't appear to have seen/received the rest of this thread, so please pardon any mistakes in advance.../disclaimer On 2001-05-16 20:49:30, Andi Gutmans [EMAIL PROTECTED] wrote: Would it make sense to try to integrate the new php_streams into this extension? It might give php_streams a push and I'm sure Wez would work with you fixing any remaining issues. It would be a nice test bed. What do you think? I'm not sure that the sockets extension would benefit from php_streams as much as php_streams would benefit from the sockets extension, if you see what I mean. I would like to see it using php_streams, as that would result in PHP being much more flexible for the person coding in PHP; they needn't worry about the type of the file handle they pass to any function. To integrate php_streams properly, ext/sockets should converge with fsock.c and use the same underlying sockets implemented as php_streams (it's not too much work). I think it's a good idea to get it done. --Wez. -- 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]
Re: [PHP-DEV] sockets extension
At 10:34 PM 5/16/2001 +0200, Daniel Beulshausen wrote: At 22:49 16.05.2001 +0300, Andi Gutmans wrote: Daniel, Would it make sense to try to integrate the new php_streams into this extension? It might give php_streams a push and I'm sure Wez would work with you fixing any remaining issues. It would be a nice test bed. What do you think? About backwards compatibility, without having read the code it sounds as if you're doing the right thing as opposed to the old module. Do any of the new function names overlap with the old ones? I'm not quite sure how we should tackle backwards compatibility here. forgot to answer that, no the new function names don't overlap, thereprefixed i.e. socket - socket_create fd_dealloc - socket_fd_free create_listen_sock - socket_create_listen The names sound good. That's for sure :) Andi -- 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]
