RE: [PHP] operational musings
Is there a well-known bug I'm up against with the IPC socket pair? If I were to revert to a standard socket approach (ie. I already posted an issue with the standard socket and nobody volunteered any help, so I switched to IPC sockets)... aren't sockets supposed to be two-way communication? -Original Message- From: Richard Lynch [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 28, 2007 4:11 PM To: Bob Dusek Cc: Robert Cummings; Jay Blanchard; php-general@lists.php.net Subject: RE: [PHP] operational musings Perhaps try just opening TWO old-school sockets, one for write, one for read... On Tue, February 27, 2007 8:12 pm, Bob Dusek wrote: The company I work for is currently doing this... using PHP in a retail environment, with a Linux server in every store, talking to the POS controller via a socket, storing data in a database (postgres), and processing retail transactions in real-time. And, sending results of those transactions to a central server (which isn't running Linux, PHP, or Apache). I'm finding the PHP socket support to be unreliable, though. Everything's fine when we have one socket open to talk to the store controller. I open the socket and bind to an address:port, the store controller connects to it just fine, and we move on. However, right now, we're using Postgres as a queue between two programs that are processing transactions. I'm trying to get rid of Postgres and use a pair of IPC sockets (created with socket_create_pair() and using pcntl_fork()). The IPC sockets seem to be totally unreliable, at this point. Sometimes, when I call socket_write(), the function just never returns. My application doesn't die but, the line of code immediately following the socket_write() function never gets executed in the parent process. The child process receives the data and logs it successfully. So, I know the socket_write function is getting called and doing something. It just never returns. Anyone here have any ideas? I can send more details, and even chunks of pertinent code. -Original Message- From: Robert Cummings [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 27, 2007 8:13 PM To: Jay Blanchard Cc: php-general@lists.php.net Subject: Re: [PHP] operational musings On Tue, 2007-02-27 at 18:59 -0600, Jay Blanchard wrote: Howdy cats and kittens! I had an interesting thought after watching a demo of a POS system and wondered if the same type of methodology could be applied in a PHP application. I haven't thought this all the way through, but a fully-hatched idea like this could signal a major change in applications designed with PHP. In the POS if the network connectivity was lost the store could continue to operate, once the network connectivity was restored the data from each store would sync back up and data would be sent to the central server, yadda, yadda, yadda. Of course this is in a client/server application with an executable residing on each workstation. So, if you wanted to do this with PHP you would likely have to have a local web /database server (each store), establish a socket (primary and store servers?) to watch for an outage/restore and then write the code to support the sync up. Can it be done with PHP? It would definitely be worth the trouble given the frequency that connections to stores get lost. Let's make a check list: local webserver -- check local database server -- check socket support -- check write code -- check All signs point to YES :) Cheers, Rob. -- .. | InterJinn Application Framework - http://www.interjinn.com | :: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `' -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- Some people have a gift link here. Know what I want? I want you to buy a CD from some starving artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] operational musings
Wow. That pretty much sums it up! I'll probably give the standard sockets another try. I'll report back on my problems. -Original Message- From: Richard Lynch [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 28, 2007 4:32 PM To: Bob Dusek Cc: Robert Cummings; Jay Blanchard; php-general@lists.php.net Subject: RE: [PHP] operational musings On Wed, February 28, 2007 3:32 pm, Bob Dusek wrote: Is there a well-known bug I'm up against with the IPC socket pair? ... aren't sockets supposed to be two-way communication? Put it this way... If my memory serves me correctly, and understanding that I'm talking about several years of list reading/posting boiled down to a couple paragraphs, and my memory HAS proven faulty in the past... I tried to do 2-way sockets and failed, filed a bug report, had it marked as bogus, and used 2 one-way sockets and went on with life. Others have posted problems in this same area, switch to 2 one-way socket, and posted hey, it works! Still others have had problems with sockets just up and dying no matter what, however, so there is no promise it will work. Only a better chance. I have NO IDEA what the new-fangled socket pair thingie is, how it works, how it's supposed to work, or if it's even implemented any different than just 2 one-way sockets, and I'm just asking you to waste your time doing in PHP what is already failing in C. But it should take you, what?, 5 minutes to try it and find out if it's better/worse? Okay, call it a day by the time you get done fixing typos and silly mistakes and really get down to a real test. Plus another 4 days to be convinced it really really works, or that the failure is consistently bad enough to be a true problem. For a true check on known problems, surf to http://bugs.php.net Way better than my memory, that's for sure. :-) -- Some people have a gift link here. Know what I want? I want you to buy a CD from some starving artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] operational musings
The company I work for is currently doing this... using PHP in a retail environment, with a Linux server in every store, talking to the POS controller via a socket, storing data in a database (postgres), and processing retail transactions in real-time. And, sending results of those transactions to a central server (which isn't running Linux, PHP, or Apache). I'm finding the PHP socket support to be unreliable, though. Everything's fine when we have one socket open to talk to the store controller. I open the socket and bind to an address:port, the store controller connects to it just fine, and we move on. However, right now, we're using Postgres as a queue between two programs that are processing transactions. I'm trying to get rid of Postgres and use a pair of IPC sockets (created with socket_create_pair() and using pcntl_fork()). The IPC sockets seem to be totally unreliable, at this point. Sometimes, when I call socket_write(), the function just never returns. My application doesn't die but, the line of code immediately following the socket_write() function never gets executed in the parent process. The child process receives the data and logs it successfully. So, I know the socket_write function is getting called and doing something. It just never returns. Anyone here have any ideas? I can send more details, and even chunks of pertinent code. -Original Message- From: Robert Cummings [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 27, 2007 8:13 PM To: Jay Blanchard Cc: php-general@lists.php.net Subject: Re: [PHP] operational musings On Tue, 2007-02-27 at 18:59 -0600, Jay Blanchard wrote: Howdy cats and kittens! I had an interesting thought after watching a demo of a POS system and wondered if the same type of methodology could be applied in a PHP application. I haven't thought this all the way through, but a fully-hatched idea like this could signal a major change in applications designed with PHP. In the POS if the network connectivity was lost the store could continue to operate, once the network connectivity was restored the data from each store would sync back up and data would be sent to the central server, yadda, yadda, yadda. Of course this is in a client/server application with an executable residing on each workstation. So, if you wanted to do this with PHP you would likely have to have a local web /database server (each store), establish a socket (primary and store servers?) to watch for an outage/restore and then write the code to support the sync up. Can it be done with PHP? It would definitely be worth the trouble given the frequency that connections to stores get lost. Let's make a check list: local webserver -- check local database server -- check socket support -- check write code -- check All signs point to YES :) Cheers, Rob. -- .. | InterJinn Application Framework - http://www.interjinn.com | :: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `' -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] operational musings
From my experience, database replication from the central server to each of the stores won't scale... We use a timed (every X minutes), home-brewed protocol that does something similar to a synchronization. And, we don't synchronize the entire database at central server (as there are parts of the central server database that only apply to specific stores). And, there's *A LOT* of data at the central server... more than you want your local server databases dealing with if they're going to keep up with any strict performance expectations (ie. a real-time transaction processing system in an very busy retail location). -Original Message- From: Jon Anderson [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 27, 2007 8:38 PM To: Jay Blanchard Cc: php-general@lists.php.net Subject: Re: [PHP] operational musings Without any more than a few minutes worth of work, you can make MySQL do that with replication. Your in-store system could act as a slave to for the central system databases (any central updates trickle down to the slave automatically) and your in-store machine could be the master for the store_xyz database(s). Network disconnect? No problem! Network reconnect? Easy! In-store machine failure? No problem! Just update the tables from the central master! Work? Almost none! And since this is a PHP list... ?= 'jon' ? Jay Blanchard wrote: Howdy cats and kittens! I had an interesting thought after watching a demo of a POS system and wondered if the same type of methodology could be applied in a PHP application. I haven't thought this all the way through, but a fully-hatched idea like this could signal a major change in applications designed with PHP. In the POS if the network connectivity was lost the store could continue to operate, once the network connectivity was restored the data from each store would sync back up and data would be sent to the central server, yadda, yadda, yadda. Of course this is in a client/server application with an executable residing on each workstation. So, if you wanted to do this with PHP you would likely have to have a local web /database server (each store), establish a socket (primary and store servers?) to watch for an outage/restore and then write the code to support the sync up. Can it be done with PHP? It would definitely be worth the trouble given the frequency that connections to stores get lost. Thanks in advance for ideas, thoughts, etc. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] multiple sockets seems problematic
Hello all, I've got a program (program X) that does the following: * opens a socket (socket A) * binds socket A to an address/port (x.x.x.x/1099) * then opens another socket (socket B), * binds socket B to an address/port (x.x.x.x/1100) * calls listen on socket B * launches a second program (program Y) with proc_open * accepts a connection on socket B (presumably from program Y) * sends a packet on socket B * reads a packet from socket B * listens on socket A== PROBLEM * accepts a connection on socket A (from whomever is trying to connect) To be clear, the socket B stuff was just added. socket A has always existed and worked just fine. Each socket resource is stored in a distinct variable. Where things go wrong, now that I've added socket B, is when I call socket_accept() on socket A... For some reason, the socket_accept($sock) call will not block, even after I've added an explicit socket_set_block($sock) call immediately preceding the socket_accept($sock) call. I don't think there are actually any connections waiting when I call socket_accept($sock), as the socket_accept call returns false. Although, the socket_strerror(socket_last_error($sock)) returns Success. This seems like the behavior I would expect if my socket was set to non-blocking. Here are the options, from socket_get_options, for socket A before I call accept: Resource id #17 [DEBUG] 0 Resource id #17 [ACCEPTCON] Resource id #17 [BROADCAST] 0 Resource id #17 [REUSEADDR] 0 Resource id #17 [KEEPALIVE] 0 Resource id #17 [LINGER] l_onoff = 0 Resource id #17 [LINGER] l_linger = 0 Resource id #17 [OOBINLINE] 0 Resource id #17 [SNDBUF] 16384 Resource id #17 [RCVBUF] 87380 Resource id #17 [ERROR] 0 Resource id #17 [TYPE] 1 Resource id #17 [DONTROUTE] 0 Resource id #17 [RCVLOWAT] 1 Resource id #17 [RCVTIMEO] sec = 0 Resource id #17 [RCVTIMEO] usec = 0 Resource id #17 [SNDLOWAT] 1 Resource id #17 [SNDTIMEO] sec = 0 Resource id #17 [SNDTIMEO] usec = 0 It seems to me that the actions I'm taking on socket B are somehow dirying socket A. Anyone know of any problems reported with this? I'm using PHP 4.3.11. But, I don't see anything in the changelogs that would indicate something like this has been fixed since 4.3.11. Also, when my socket_accept call fails for socket A, I try to close the socket and re-open it, but (even after calling socket_close) when I try to bind to the same address/port as I did the first time around, socket_bind fails and tells me Address already in use... (and I try it repeatedly, sleeping 5 seconds between attempts, and it never becomes available). Any help or pointers would be appreciated. Thanks, Bob -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] time
If you have the timezone offset stored for each contact, you can compare that to the timezone offset of the server and do the math on a timestamp value. // return value format: hhmm // -0500 for US/EST, -5 hours relative to GMT $timeZoneOfServer = date(O); -Original Message- From: Richard Kurth [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 30, 2007 12:12 AM To: php-general@lists.php.net Subject: RE: [PHP] time [snip] I am writing a program for managing leads and contacts. I would like to add the ability to see what TIME it is where the contact is not there server time. So if you looked at a list of contacts from all over the country you would see different times compared to what time it is where the user is at. What should I be looking at to calculate out the different time zones. Could somebody just point me in the write direction at this time I have no idea on how to proceeded. [/snip] You would use JavaScript to capture their local 'browser' time and process it with PHP I am not looking for something where I am on line with these people some do not have internet access. I would be calling them on the phone. I need a way to get the time at there location using what info I already have like the address zip code and phone number. It would probably have to be compared to a database of some sort or the time zone file on a lynx server. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] busy message queues
Hello all, I'm looking for some advice from people that have experience with inter-process messaging queues. If you have experience with this sort of thing, I would appreciate any advice you can give... I'm working on an application that is extremely performance-sensitive. And, we're passing a lot of messages back and forth between two running programs. We've been using Postgres for our messaging queues up to now, but our message volume seems a bit higher than what we'd expect Postgres to keep up with... many inserts/deletes from in/out queues seems to dirty a lot of memory and effect general database performance (we use the database significantly for other operations). One option we're looking at is local sockets. Another option is shared memory. Shared memory seems like it might not work as we need it, though, given the limited semaphore capabilities of PHP. Another option is msg_get_queue() operations. This will be a bigger deal... our client does not currently have --enable-sysvmsg built into their PHP, and they have 1800+ servers to update everytime something like this is changed. So, I'm leaning toward local sockets. I'm implementing this right now, so I can test the performance against the Postgres implementation. I will also implement and test other solutions if anyone can persuade me... ie. if you feel the msg_get_queue() stuff is worth the compile/installation effort. Any help will be appreciated. Thanks, Bob -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] busy message queues
So, I'm leaning toward local sockets. I'm implementing this right now, so I can test the performance against the Postgres implementation. I will also implement and test other solutions if anyone can persuade me... ie. if you feel the msg_get_queue() stuff is worth the compile/installation effort. You'll be comparing a mammoth to a moth swarm. Do you actually need the persistence PostgreSQL gives you, or don't you mind if the other side is down? If you need to be sure that the receiver will process your message even if it's not up when you send the message, you'll end up reinventing a database. No. We don't need the persistence. I'm planning on managing the flow and not sending the data if the app isn't available to receive it on the other end. What version of PostgreSQL are you using? 7.4.x What's your vacuuming strategy? We've played around with a lot of them. Overall, it doesn't do too bad. But, we're trying to squeeze as much out of it as we can. -- How many Vietnam vets does it take to screw in a light bulb? You don't know, man. You don't KNOW. Cause you weren't THERE. http://bash.org/?255991 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] busy message queues
No. We don't need the persistence. I'm planning on managing the flow and not sending the data if the app isn't available to receive it on the other end. Will you need to resend? Nope. Not in-line. We have an off-line message processing procedure to handle the missed transactions. What version of PostgreSQL are you using? 7.4.x Too old, 8.1 and 8.2 have way better performance. Yikes. This may be something we do by the end of the year. The client's on SLES9, so we can go as high as they support for SLES9. What's your vacuuming strategy? We've played around with a lot of them. Overall, it doesn't do too bad. But, we're trying to squeeze as much out of it as we can. If 7.4 isn't too bad, you should be happy with 8.2. You should really asses the newer versions before diving into redoing your messaging from scratch. BTW, with 1800 servers, I'd expect you'll have a centralized automated package rollout. Yeah... software rollouts and package updates are generally done in an automated fashion. We'll probably test 8.X as part of our evaluation process. If the sockets don't gain us much/anything, and the new PG version doesn't prove to gain us much, I suppose we'll try to compile the get_message_queue stuff. Any predictions on what we might see for performance without upgrading the PG version? Thanks for your feedback, thus far. It's good to hear what others think about this, as I'm pretty uncertain which direction to concentrate in. I've already got some stuff done on the local sockets. Bob -- How many Vietnam vets does it take to screw in a light bulb? You don't know, man. You don't KNOW. Cause you weren't THERE. http://bash.org/?255991 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] stream_socket_pair
Are sockets created via stream_socket_pair more efficient for IPC than standard socket/port communications? I want to open a process with proc_open, and I want to use a socket to for IPC. One solution is to just create a socket in the parent and pass the port number to the child. Then, when the child starts, it would connect to the local port via a socket. Would it be better to use stream_socket_pair to create a pair of IPC socets and then somehow pass the socket descriptor via the proc_open call? Does anyone have any experience passing a socket handle via the descriptor array in proc_open? Thanks, Bob -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
