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:ceo@xxxxxxxxx] > Sent: Wednesday, February 28, 2007 4:11 PM > To: Bob Dusek > Cc: Robert Cummings; Jay Blanchard; php-general@xxxxxxxxxxxxx > Subject: RE: 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:robert@xxxxxxxxxxxxx] > >> Sent: Tuesday, February 27, 2007 8:13 PM > >> To: Jay Blanchard > >> Cc: php-general@xxxxxxxxxxxxx > >> Subject: Re: 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
