[PHP/HL7] - Socket blijft onbeperkt

[gvanh]

Heren en damesch,

Voor een gegevensuitwisseling met een HL7 berichtenserver heb ik in PHP een (op een PEAR package gebaseerde) set classes geschreven voor het opstellen van de HL7 berichten en het verwerken van de response.

Samenstellen van berichten gaat allemaal fantastisch en mooi, enige probleem waarmee ik zit, is de communicatie met de server over een socket. Het opzetten van de socket gaat goed, en versturen van de data gaat goed en het ontvangen van de gegevens gaat goed. Maarrrr ... het inlezen van de data uit de socket-connectie gaat mis. Er wordt wel data ontvangen (volgens mij zelfs het volledige bericht), maar toch blijft de loop waarin de data wordt ingelezen hangen. Vreemde is dat geen enkele timeout ervoor zorgt dat het script ermee ophoudt (na bijvoorbeeld 30 seconde). Vervelend is vervolgens, dat de socket-verbinding open blijft staan, waardoor ik geen nieuwe verbinding kan maken. Immers ... de berichtenserver vindt dat er nog een verbinding openstaat en "Actively refuses" een nieuwe verbinding. De reeds bestaande verbinding kan ik echter in PHP niet opnieuw gebruiken, maar ook niet afsluiten. Dat maakt debuggen er ook niet eenvoudiger op.

Een stukje code:

code:

private function _connect($host, $port) {
    $socket = socket_create(AF_INET, SOCK_STREAM, SOL_TCP);
    if ( $socket < 0 ) return false;
    socket_set_option($socket, SOL_SOCKET, SO_SNDTIMEO, array("sec" => 2, "usec" => 0));
    $result = socket_connect($socket, $host, $port);
    if ( $result === false ) return false;
    return $socket;
} // _connect()

public function send($req) {
    global $logger;
    
    $hl7Msg = $req->toString();

    $rs = socket_write($this->_handle, $this->_message_prefix.$hl7Msg.$this->_message_suffix);
    if ( $rs === false ) return false;
    
    $logger->logmsg("HL7 Message has been sent.");

    $data = ''; $timeout = time() + 5;
    while( $buf = socket_read($this->_handle, $this->_max_read, PHP_BINARY_READ) ) {
        $data .= $buf;
        $logger->logmsg("Read from buffer: {$buf}.");
        if ( preg_match('/' . $this->_message_prefix. "$/", $buf) ) break;
        if ( (time()) > $timeout ) break;
    }

    $logger->logmsg("Finished while() loop with socket_read().");

    // Remove message prefix and suffix
    $data = preg_replace("/^" . $this->_message_prefix . "/", "", $data);
    $data = preg_replace("/" . $this->_message_suffix . "$/", "", $data);
    $resp = new HL7_Message($data);
    return $resp;
} // send()

De logger logt berichten naar een bestand, zodat ik kan zien waar de uitvoering wel/niet komt.
- Regel 28 wordt nooit bereikt.
- Regel 23 wordt 1 keer aangeroepen en bevat dan ook keurig het responsbericht dat ik nodig heb.

Ik heb dus het vermoeden dat bij de tweede keer socket_read ergens iets misgaat, waardoor het script eindeloos ergens op blijft wachten.

Het script wordt uitgevoerd op een Windows Server 2003. Ergens in de handleiding van PHP heb ik gevonden dat op windows server de socket_read geen (bool)false teruggeeft wanneer hij klaar is met lezen, maar dat hij dan een lege string ("") teruggeeft.

Iemand een idee of mijn aanpak verkeerd is, danwel andere suggesties?

[CodeCaster]

quote: http://nl3.php.net/socket_read

PHP_BINARY_READ - works, but returns '', not FALSE...
- is blocking, until data received or connection closed
- does pass-through \r\n etc.
- returns data on data, '' on connection closed
- you can detect closed connection by checking for '' (not FALSE as stated i manual)

Dus

PHP:

  while( $buf != '') {
    $buf = socket_read($this->_handle, $this->_max_read, PHP_BINARY_READ) 
  }

Zoiets?

[Janoz]

Alhoewel de oplossing van CodeCaster waarschijnlijk wel gaat werken is deze ook niet helemaal safe. Wanneer je script sneller is dan de berichtenserver kan het best zijn dat er nog geen response is op het moment dat je wat leest waardoor de lus al afsluit voordat er een antwoord verzonden is.

Beter is om je response gewoon te parsen tijdens het inlezen. Je weet dan zeker dat je het bericht helemaal ontvangen hebt en zekerheid lijkt me wel behoorlijk belangrijk in een medische omgeving.

[ Voor 7% gewijzigd door Janoz op 23-01-2009 10:52 ]

[CodeCaster]

Nee, toch? Hij blockt op socket_read totdat er data is of totdat de verbinding wordt verbroken.

[Janoz]

Daarin zou je heel goed gelijk kunnen hebben. Ik kon het zo snel op de socket_read pagina niet vinden, maar ik moet zeggen dat ik helemaal niet heb gezocht naar blocking en non blocking.

Probleem blijft wel, maar zit dan aan de andere kant. Je maakt je afhankelijk van het door de server sluiten van de socket.

[gvanh]

Dank voor de reacties to zover.

Ik heb inmiddels de while() loop aangepast naar aanleiding van de reactie van CodeCaster.

Wat ik niet helemaal snap, is dat het op dit moment niet zozeer lijkt te zijn dat de while-loop onbeperkt blijft doorlopen, dan zou immers het logbestand ook moeten vollopen met een regel voor iedere keer dat de loop doorlopen worden. Nee, het logbestand krijgt de betreffende regel maar 1x toegevoegd. Maar blijkbaar loopt de loop de "vast" de tweede keer dat socket_read wordt aangeroepen.

Helaas kan ik nu nog niet testen, omdat de verbinding nog steeds niet (meer) bruikbaar is omdat er nog een oude verbinding openstaan.

[farlane]

gvanh schreef op vrijdag 23 januari 2009 @ 12:57:
Dank voor de reacties to zover.

Ik heb inmiddels de while() loop aangepast naar aanleiding van de reactie van CodeCaster.

Wat ik niet helemaal snap, is dat het op dit moment niet zozeer lijkt te zijn dat de while-loop onbeperkt blijft doorlopen, dan zou immers het logbestand ook moeten vollopen met een regel voor iedere keer dat de loop doorlopen worden. Nee, het logbestand krijgt de betreffende regel maar 1x toegevoegd. Maar blijkbaar loopt de loop de "vast" de tweede keer dat socket_read wordt aangeroepen.

Helaas kan ik nu nog niet testen, omdat de verbinding nog steeds niet (meer) bruikbaar is omdat er nog een oude verbinding openstaan.

Als er geen data wordt ontvangen en de server ook de socket niet sluit blijft ie daar hangen ja. Je mist een timeout constructie.

[gvanh]

farlane schreef op vrijdag 23 januari 2009 @ 14:10:
[...]
Als er geen data wordt ontvangen en de server ook de socket niet sluit blijft ie daar hangen ja. Je mist een timeout constructie.

Maar wat voor timeout constructie zou daar dan nog in moeten?
Ik heb immers wel al een timeout constructie om ervoor te zorgen dat de while-loop niet blijft hangen.
Alleen heb ik dus niet het idee dat de while() loop onbeperkt blijft doorlopen, maar eerder dat er bij die socket_read() iets blijft hangen, de tweede keer dat hij daaruit iets gaat lezen.

[farlane]

gvanh schreef op zondag 25 januari 2009 @ 13:34:
[...]
Alleen heb ik dus niet het idee dat de while() loop onbeperkt blijft doorlopen, maar eerder dat er bij die socket_read() iets blijft hangen, de tweede keer dat hij daaruit iets gaat lezen.

Idd, je moet dus op die socket_read een timeout constructie hebben die na x tijd gewacht te hebben met een melding komt "er is geen data".
Nou heb ik geen kennis van PHP maar ik heb een sterk vermoeden dat PHP ook wel een socket_select kent.

[gvanh]

farlane schreef op zondag 25 januari 2009 @ 19:11:
[...]
Idd, je moet dus op die socket_read een timeout constructie hebben die na x tijd gewacht te hebben met een melding komt "er is geen data".
Nou heb ik geen kennis van PHP maar ik heb een sterk vermoeden dat PHP ook wel een socket_select kent.

Die is er inderdaad. Gisterenavond daarover het één en ander gelezen. Naar aanleiding daarvan heb ik mijn code voor het inlezen van de data veranderd tot zoiets. Is dat een logische opzet zo?

PHP:

        $data = ''; $timeout = time() + 5;
        while ( time() <= $timeout ) {
            $set = array($socket);
            if ( socket_select($set, $set_w = NULL, $set_e = NULL, 1, 0) > 0 ) {
                foreach ( $set as $sock ) {
                    if ( ($read = socket_read($sock, 1024)) === false || $read == '' ) {
                        if ( $read != '' ) {
                            $d->prt('Read error');
                        } else {
                            socket_close($sock);
                        }
                    } else {
                        $data .= $read;
                    }
                }
            }
        } // while()

[Confusion]

gvanh schreef op vrijdag 23 januari 2009 @ 10:34:
Voor een gegevensuitwisseling met een HL7 berichtenserver heb ik in PHP een (op een PEAR package gebaseerde) set classes geschreven voor het opstellen van de HL7 berichten en het verwerken van de response.

Biedt de betreffende server geen webservice aan? Voorzover ik weet wordt de meeste HL7 tegenwoordig in SOAP gewrapped. In dat geval moet je vooral niet zelf met sockets aan de slag gaan, maar er gewoon een library inschuiven waarmee je een webservice kan consumeren.

[ Voor 4% gewijzigd door Confusion op 26-01-2009 07:53 ]

[gvanh]

Confusion schreef op maandag 26 januari 2009 @ 07:51:
[...]
Biedt de betreffende server geen webservice aan? Voorzover ik weet wordt de meeste HL7 tegenwoordig in SOAP gewrapped. In dat geval moet je vooral niet zelf met sockets aan de slag gaan, maar er gewoon een library inschuiven waarmee je een webservice kan consumeren.

Hmmm ... nee ... voor zover ik weet is dit de enige manier waarop het wordt aangeboden. Ik zal nog even navragen voor de zekerheid. Maar HL7 draait ook nog in oudere versie (2.4), terwijl nieuwere versie 3 alle communicatie ook in XML verstuurt en ontvangt ... zou mijn voorkeur hebben.

[Janoz]

gvanh schreef op maandag 26 januari 2009 @ 07:40:
Is dat een logische opzet zo?

Blijkbaar sluit de server de connectie niet zelf. Het is absoluut niet logisch dat je voor de normale werking van je applicatie afhankelijk bent van timeouts.

Mijn hl7 kennis is wat roestig en toen ik een paar jaar terug er mee heb gewerkt ging dat ook via een abstractie laag, maar ik kan me zo herinneren dat via een verbinding meerdere requests verstuurd zouden kunnen worden. In dat geval is het heel logisch dat de server de verbinding open laat. Wanneer je klaar bent wordt van je verwacht om zelf de verbinding te sluiten. En lees met die informatie mijn eerste post in dit topic nog maar eens een keertje. Jij weet wat je binnen moet krijgen en wanneer het bericht klaar is, dus je weet ook wanneer de socket weer dicht kan.

[ Voor 7% gewijzigd door Janoz op 26-01-2009 09:02 ]

[farlane]

gvanh schreef op maandag 26 januari 2009 @ 07:40:
Die is er inderdaad. Gisterenavond daarover het één en ander gelezen. Naar aanleiding daarvan heb ik mijn code voor het inlezen van de data veranderd tot zoiets. Is dat een logische opzet zo?

Ding is dat je routine nu _altijd_ 5s bezig is met het afhandelen, je zou nog uit de while kunnen breaken als je verwachte antwoord binnen is. Verder lijkt het wel een plausibele constructie.

[farlane]

Janoz schreef op maandag 26 januari 2009 @ 09:00:
Blijkbaar sluit de server de connectie niet zelf. Het is absoluut niet logisch dat je voor de normale werking van je applicatie afhankelijk bent van timeouts.

De stabiele werking van een applicatie is, als er communicatie aan te pas komt, altijd afhankelijk van timeouts.

[gvanh]

farlane schreef op maandag 26 januari 2009 @ 09:03:
[...]
Ding is dat je routine nu _altijd_ 5s bezig is met het afhandelen, je zou nog uit de while kunnen breaken als je verwachte antwoord binnen is. Verder lijkt het wel een plausibele constructie.

Ah ja ... da's wel een goeie. Dan bij deze nog de volgende aanpassing aan de code:

PHP:

        $abort = false; $data = ''; $timeout = time() + 5;
        while ( !$abort && (time() <= $timeout) ) {
            $set = array($socket);
            if ( socket_select($set, $set_w = NULL, $set_e = NULL, 1, 0) > 0 ) {
                foreach ( $set as $sock ) {
                    if ( ($read = socket_read($sock, 1024)) === false || $read == '' ) {
                        if ( $read != '' ) {
                            $d->prt('Read error');
                        } else {
                            socket_close($sock);
                            $abort = true;
                        }
                    } else {
                        $data .= $read;
                        if ( (substr($data, 0, strlen($this->_message_prefix)) == $this->_message_prefix)
                                && substr($data, -1 * strlen($this->_message_suffix), strlen($this->_message_suffix)) == $this->_message_suffix 
                        ) {
                            $abort = true;
                        }
                    }
                }
            }
        } // while()

Wanneer je klaar bent wordt van je verwacht om zelf de verbinding te sluiten.

Ja ... dat is natuurlijk zo ... maar het ging vooral mis bij het tweede keer aanroepen van socket_read(), waardoor het script bleef hangen op socket_read(). Ik hoop dat ik dat hiermee nu heb ondervangen. Als het zo werkt, kan ik gaan tweaken om de boel "mooier" te krijgen.

[ Voor 13% gewijzigd door gvanh op 26-01-2009 09:14 . Reden: tweede reactie toegevoegd. ]

[Janoz]

farlane schreef op maandag 26 januari 2009 @ 09:05:
[...]


De stabiele werking van een applicatie is, als er communicatie aan te pas komt, altijd afhankelijk van timeouts.

Met 'normale werking' bedoel ik de happy path door je applicatie. Dat is niet hetzelfde als 'stabiele werking'. Het is toch niet normaal dat je voor de afhandeling van je bericht altijd x seconden nodig hebt omdat je x seconde wacht om door te hebben dat er eigenlijk geen communicatie meer is?

[Janoz]

gvanh schreef op maandag 26 januari 2009 @ 09:10:
Ja ... dat is natuurlijk zo ... maar het ging vooral mis bij het tweede keer aanroepen van socket_read(), waardoor het script bleef hangen op socket_read(). Ik hoop dat ik dat hiermee nu heb ondervangen. Als het zo werkt, kan ik gaan tweaken om de boel "mooier" te krijgen.

Maar waarom roep je de socket_read nog aan terwijl je eigenlijk helemaal geen data meer vewacht? Zoals ik Farlane ook al probeer uit te legen zijn timeouts bedoeld voor de exceptionele gevallen.

[gvanh]

Janoz schreef op maandag 26 januari 2009 @ 09:15:
[...]

Met 'normale werking' bedoel ik de happy path door je applicatie. Dat is niet hetzelfde als 'stabiele werking'. Het is toch niet normaal dat je voor de afhandeling van je bericht altijd x seconden nodig hebt omdat je x seconde wacht om door te hebben dat er eigenlijk geen communicatie meer is?

Eens ... wat dat betreft was mijn een-na-laatste code inderdaad niet erg handig. Met onderstaande code-toevoeging hoop ik dat dus beter op te lossen:

PHP:

if ( (substr($data, 0, strlen($this->_message_prefix)) == $this->_message_prefix)
    && substr($data, -1 * strlen($this->_message_suffix), strlen($this->_message_suffix)) == $this->_message_suffix 
  ) {
    $abort = true;
  }

[ Voor 6% gewijzigd door gvanh op 26-01-2009 09:18 ]

[gvanh]

Janoz schreef op maandag 26 januari 2009 @ 09:17:
[...]Maar waarom roep je de socket_read nog aan terwijl je eigenlijk helemaal geen data meer vewacht? Zoals ik Farlane ook al probeer uit te legen zijn timeouts bedoeld voor de exceptionele gevallen.

Nou ... mijn initiële idee was om socket_read aan te roepen net zolang tot er geen data meer wordt ontvangen. Op het moment dat er geen data meer wordt ontvangen, is blijkbaar alle data binnen en kan ik de connectie sluiten. Hierin heb ik analoog gedacht aan hoe je een bestand inleest. Maar naar ik nu begrijp, gaat die analogie niet op.

[farlane]

Janoz schreef op maandag 26 januari 2009 @ 09:15:
Met 'normale werking' bedoel ik de happy path door je applicatie. Dat is niet hetzelfde als 'stabiele werking'. Het is toch niet normaal dat je voor de afhandeling van je bericht altijd x seconden nodig hebt omdat je x seconde wacht om door te hebben dat er eigenlijk geen communicatie meer is?

Als eerste is het natuurlijk belangrijk dat je het protocol volgt, dus een read als er volgens het protocol geen data meer komt is onzinning. Het was ook niet zozeer een quote om aan te geven dat je geen gelijk had maar meer om aan te geven dat, als je met communicatie bezig bent, en je iets verwacht van de 'andere kant' er _altijd_ sprake moet zijn van een timeout constructie.

[farlane]

gvanh schreef op maandag 26 januari 2009 @ 09:17:
Eens ... wat dat betreft was mijn een-na-laatste code inderdaad niet erg handig. Met onderstaande code-toevoeging hoop ik dat dus beter op te lossen:

De socket close kan btw buiten je while loop, aangezien je nu, als je uit je while komt altijd 'klaar' bent ( met een timeout of niet )

frickY schreef op maandag 26 januari 2009 @ 09:31:
Grote kans dat de server het antwoord in 1x verzend, en je socket_read dus ook maar 1x hoeft aan te roepen.

Dat geldt alleen voor TCP overigens.

[ Voor 24% gewijzigd door farlane op 26-01-2009 09:50 ]

[frickY]

gvanh schreef op vrijdag 23 januari 2009 @ 12:57:
Wat ik niet helemaal snap, is dat het op dit moment niet zozeer lijkt te zijn dat de while-loop onbeperkt blijft doorlopen, dan zou immers het logbestand ook moeten vollopen met een regel voor iedere keer dat de loop doorlopen worden. Nee, het logbestand krijgt de betreffende regel maar 1x toegevoegd. Maar blijkbaar loopt de loop de "vast" de tweede keer dat socket_read wordt aangeroepen.

Dat loopt je verbinding in blocking-mode. De read functie blijft dan hangen totdat hij data ontvangt.
Ook mogelijk dat de server geen, of een andere, linebreak verstuurd, waardoor je read functie niet weet dat hij alles binnen heeft.

Grote kans dat de server het antwoord in 1x verzend, en je socket_read dus ook maar 1x hoeft aan te roepen. Veranderd je while() eens in een if()
Anders kun je wellicht beter in non-blocking mode verder. Ik weet niet of de server eerst een header geeft met daarin de berichtlengte? Die kun je dan gebruiken om te tellen of je alles al binnen hebt, en dan zelf de connectie sluiten.

[gvanh]

Naar nu blijkt lag de fout aan de kant van de HL7-berichtenserver. Voor een juiste uitwisseling van data moest er blijkbaar nog wat meer ingesteld worden. Dat is nu gedaan en het geheel loopt als een zonnetje. Het "vastlopen" dat ik had, was dus niet normaal gedrag, maar had een diepere oorzaak.

Zonde van de tijd ... maar ik heb wel weer een hoop geleerd over sockets de afgelopen twee weken ... dat is dan weer de keerzijde. Code die er nu staat is ook mooier dan wat ik aanvankelijk had, dus daar ook winst.

Dank voor al jullie input.