[PHP-DEV] Re: Sockets Extension Rework (API, etc...) VERY LONG
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
vs.
while(($retval==socket_read($sock, $buf, $len)) 0) {
// do something
}
if ($retval==-1) {
print strerror(socket_last_error($sock));
} elseif ($retval==0) {
$eof=1;
print Eof has occured!!!;
}
what about
while(socket_read($sock, $buf, $len)) {
// do somthing
}
switch (socket_last_error($sock)) {
case SOCKET_EOF:
print eof;
break;
default:
print strerror(socket_last_message($sock));
}
harald.
-BEGIN PGP SIGNATURE-
Version: PGP 7.0.4
iQA/AwUBPHeMRK1+myS9SSHxEQK7TgCcCP8Z4vdnVfFOhjhBX+y/WBQ196UAoKl1
BPYcQ7yUWFo/O0VeJwf/9lE6
=xYWI
-END PGP SIGNATURE-
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Sockets Extension Rework (API, etc...) VERY LONG
On Wed, 2002-02-20 at 19:29, Richard Samar wrote: Hi Jason, Hello Richard, I was the extension user talking about a few of the problems :-) I still had not the time to take a look at all the functions. 1. Consistency problems a. Some functions take host, some take ip, some take both b. Parts of the code use socklen_t, parts use int c. Windows code doesn't support PHP_NORMAL_READ d. Some protos are off with the function +1 to all of that and adding that: that stuff like arg1, arg2, arg3arg6 should get sensible variable names. %-) Agreed. 2. Logic Problems a. Max fd code does not work correctly (wrong approach) b. socket_recv does not properly handle error conditions 3. API problems [...] b. socket_create_listen only allows a listener to be installed on the local interface I think this is the idea behind this function which is actually a combination of creating binding and listening (if I recall correctly) for connection-oriented sockets. I would keep this, as this is just a quick and handy version for the probable most used server-socket. Right, and I am not suggesting getting rid of it. I was merely saying that if the function creates on the local interface only, it should be called socket_create_local_listen() instead. I think the concept of a quick socket bind listen is a great idea; however it should allow you to bind on any ip not just 127.0.0.1 (which should actually be INADDR_LOOPBACK) My suggestion is the following syntax change: socket_create_listen(port, [host/ip], [backlog]); c. socket_last_error clears the last error after reading (WTF) I think that this is meant to be so too. It does appear that this was meant to be this way; however, the only reason I can think of for that behavior, would be using socket_last_error() as an error check like if(socket_last_error) print error has occured. If that was the intended reason, I don't think it is very intuitive. actually there wouldn't be that many BC concerns through the named changes. An entire review would be good as some more little bugs might be found which prevented the use of the extension anyways. Well it would break anyone's code using socket_fd_*, socket_select, or socket_recv. However, I think that the users of those functions would have no problem adapting. I thought about changing socket_read to the same behavior that I am planning for socket_recv, but I think the purpose of socket_read is to be a very simple and easy to use function for reading sockets. If the time has come for the app to catch all conditions, then socket_recv() is the way to go. -jason -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Sockets Extension Rework (API, etc...) VERY LONG
I'm all for fixing this extension up to make it better, but I'm a little concerned with totally dropping the fd_* functions. How would you mimic their use in something like a multiplexing using a blocking call situation after the change? I have no idea how it can be done without using the fd_* function. (But then again, I'm used to using the FD_* macros in C, so maybe there's better way in PHP.) Just wondering, because I acutally use this extension in a multiplexing kind of way with indefinite socket_select blocking and multiple clients and all that jazz already. Yeah, I know it's experimental and stuff, but it has yet to fail, even with my daemon script running for weeks on end under a fair load. I use the socket functions in a search engine that's constantly listening for connections using socket_select, and the socket_fd* functions are used quite a bit, hence my concern. (Not that I'm adverse to the change, 'cause I'm sure I'll cope, but I'd like to know if it will be possible to port my existing stuff over to the new API.) J Jason Greene wrote: 2. Get rid of socket_fd_*. - It makes little sense to make fd masks available to the user, because this can be much easier to handle by using arrays. This will fix the max_fd code that attempts to calculate the highest file descriptor in the fd_set. Select would then look like socket_select (array read_socks(), array write_socks(), array except_socks(), int tv_sec, int uv_sec) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Sockets Extension Rework (API, etc...) VERY LONG
On Thu, 2002-02-21 at 18:09, J Smith wrote: I'm all for fixing this extension up to make it better, Great!!! but I'm a little concerned with totally dropping the fd_* functions. How would you mimic their use in something like a multiplexing using a blocking call situation after the change? I have no idea how it can be done without using the fd_* function. (But then again, I'm used to using the FD_* macros in C, so maybe there's better way in PHP.) Well, since you know the C-API, lets look at if from the C socket API perspective. select() is designed to take 3 arrays. The problem with arrays is that they take up memory and processing time. In application space this really isn't a problem, but in the kernel, every saved byte counts. To optimize this they emulated arrays using bit masks. Another optimization they performed is to have you pass the highest file descriptor + 1 into select. (that way they only process part of the bit mask.) What I am getting at, is that FD_* was an interface designed strictly for kernel performance. Direct manipulation of these low level values does not really belong in a high-level language. The method that makes the most sense is to use php arrays in place of the fd masks. Everything would work exactly the same, except it would be much easier to interface, it would be less buggy, and require less code. By the way, the bug with the socket_fd_functions, is that it may set your maximum file descriptor incorrectly, and this would cause you to miss events occurring on ready sockets. (This occurs anytime you call socket_fd_clear() on a socket, or if you don't add sockets in order they were opened ex. 3, 1, 2 will cause you to lose file descriptor 3. example ?php // ... $read_flds=array($socket1, $socket2, $socket3, $socket4, $socket5); $write_flds=array($socket6, $socket7, $socket8); $except_flds=array($socket9); // Wait on sockets specified in arrays, and modify them to contain // sockets that are ready $retval = socket_select($read_flds, $write_flds, $except_flds, 1); //Perform actions on sockets waiting to be read foreach($read_flds as $read_sock) perform_read_action($read_sock); //Perform actions on sockets waiting to be written foreach($write_flds as $write_sock) perform_write_action($write_sock); //Perform actions on exceptions foreach($except_flds as $except_sock) process_exception($except_sock); // ... ? Just wondering, because I acutally use this extension in a multiplexing kind of way with indefinite socket_select blocking and multiple clients and all that jazz already. Yeah, I know it's experimental and stuff, but it has yet to fail, even with my daemon script running for weeks on end under a fair load. I use the socket functions in a search engine that's constantly listening for connections using socket_select, and the socket_fd* functions are used quite a bit, hence my concern. (Not that I'm adverse to the change, 'cause I'm sure I'll cope, but I'd like to know if it will be possible to port my existing stuff over to the new API.) I would like to see this extension become stable so that people can start relying on somewhat frozen behavior. To answer your question It should be pretty easy to port your code to the newer API. I appreciate hearing concerns like this, and I hope you and others continue to speak up. : ) -Jason J Jason Greene wrote: 2. Get rid of socket_fd_*. - It makes little sense to make fd masks available to the user, because this can be much easier to handle by using arrays. This will fix the max_fd code that attempts to calculate the highest file descriptor in the fd_set. Select would then look like socket_select (array read_socks(), array write_socks(), array except_socks(), int tv_sec, int uv_sec) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- Jason T. Greene Internet Software Engineer [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Use PHP: http://www.php.net -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Sockets Extension Rework (API, etc...) VERY LONG
Hi Jason, I was the extension user talking about a few of the problems :-) I still had not the time to take a look at all the functions. 1. Consistency problems a. Some functions take host, some take ip, some take both b. Parts of the code use socklen_t, parts use int c. Windows code doesn't support PHP_NORMAL_READ d. Some protos are off with the function +1 to all of that and adding that: that stuff like arg1, arg2, arg3arg6 should get sensible variable names. %-) 2. Logic Problems a. Max fd code does not work correctly (wrong approach) b. socket_recv does not properly handle error conditions 3. API problems [...] b. socket_create_listen only allows a listener to be installed on the local interface I think this is the idea behind this function which is actually a combination of creating binding and listening (if I recall correctly) for connection-oriented sockets. I would keep this, as this is just a quick and handy version for the probable most used server-socket. c. socket_last_error clears the last error after reading (WTF) I think that this is meant to be so too. 2. Get rid of socket_fd_*. - yes. a very important thing. I didn't take a deep look at everything but it seemed to try matching the C functions 1:1. It makes little sense to make fd masks available to the user, because this can be much easier to handle by using arrays. I had the very same idea. This will fix the max_fd code that attempts to calculate the highest file descriptor in the fd_set. Select would then look like socket_select (array read_socks(), array write_socks(), array except_socks(), int tv_sec, int uv_sec) :-) 3. Add socket_clear_error(), and change socket_last_error() to not clear - I think that socket_last_error() clearing the last error is a huge WTF I am not sure about this. I don't think that it is a big problem. but...wtf ;-) I guess it is not such a big change. 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. actually there wouldn't be that many BC concerns through the named changes. An entire review would be good as some more little bugs might be found which prevented the use of the extension anyways. greetz -moh -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Sockets Extension Rework (API, etc...) VERY LONG
...posting at 2:30am can lead to interesting sentence constructions. my appologies :-) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
