PHP + CURL: hoe verwachtte timeout niet als error behandelen

[!null]

Hallo

Ik ben ben een telefooncentrale aan het uitlezen met cURL in PHP, opzich is het vrij vanzelfsprekend allemaal. Echter heeft de telefooncentrale geen nette http implementatie met afsluiting etc, nee het is gewoon rauwe data en hij laat je eeuwig wachten om je steeds de laatste info door te geven. (verbinden lukt wel meteen, dus in die zin geen timeout)
Nou wil je met een PHP script niet eeuwig wachten dus geef ik een timeout mee (CURLOPT_TIMEOUT, op 5 seconden) zodat ie de aanwezige data heeft kunnen laden, en daarna gewoon stopt. Ook dit werkt prima tot het volgende.
Ik wil niet dat ie de data rechtstreeks uitspuugt maar het me teruggeeft, dat bereik ik met de CURLOPT_RETURNTRANSFER flag. Alleen geeft ie in deze situatie een False terug ipv de data, omdat hij de timeout als error ziet, ook al heeft ie wel degelijk data ontvangen.

Hoe kom ik nu netjes bij m'n data? Ik zie geen flags waardoor ik de timeout niet als error kan laten gelden.

[RobIII]

Weet je zeker dat PHP dan wel de juiste tool is? Iets met 'right tool for the right job' enzo.

offtopic:
Met Asterisk aan 't spelen?

[!null]

Misschien niet helemaal de right tool, maar het zou toch wel makkelijk zijn. Aangezien PHP lekker snel ontwikkelen is, en we het e.e.a. willen integreren in bestaande webapplicatie + database. En de output is CSV dus dat werkt ook heel snel. Het doel is dus de nodige data/statistieken eruit halen, meer niet.

Daarnaast ben ik er al bijna, en wil ie me de data gewoon niet geven omdat ie denkt dat er iets fout gegaan is. Krijg je een error terug in de zin van: Operation timed out after 5 seconds with 163 bytes received (best irritant)

[crisp]

CURLOPT_RETURNTRANSFER op FALSE zetten en de output opvangen in een buffer?

[!null]

Hmm, misschien kan ik iets met CURLOPT_FILE, maar dan niet naar een file laten schrijven, maar naar een stream/buffer oid. Dus een stream ipv een filepointer.

Als het moet dan maar naar een tijdelijke file. (maar liever niet, want ik wil het direct live kunnen zetten zonder zorgen over rechten)

Edit:
Volgens mij kan ik hier wel iets mee, http://nl3.php.net/wrappers.php
En dan gaat het vooral om de php://memory/ stream

[ Voor 27% gewijzigd door !null op 16-04-2008 11:49 ]

[crisp]

Ik bedoel meer zoiets:

PHP:

ob_start();
$success = curl_exec($ch);
$respons = ob_get_contents();
ob_end_clean();

[!null]

Hee dat is makkelijk. Dat kende ik eigenlijk helemaal niet. Dit is wel het simpelste te implementeren.
Hoef ik ook niet meer naar streams te kijken. Ik ga hiermee aan de slag, dankje!

Edit: Werkt perfect zoals verwacht. Dankje.
Nu al die ongedocumenteerde meuk van die telefooncentrale goed parsen.

[ Voor 24% gewijzigd door !null op 16-04-2008 12:18 ]

[Niemand_Anders]

De niet afsluiting heet Keep-Alive. Daarmee is het mogelijk in dezelfde stream relevante bestanden op te halen zoals images en css stylesheets. Daarmee voorkom je extra overhead van het opzetten van tcp verbindingen.

Omdat jij geen kennis hebt van het HTTP protocol, betekend nog niet automatisch dat de telefooncentrale geen nette afsluiting kent. Het HTTP protocol is zeer goed gedocumenteert, dus waarschijnlijk is het niet zo heel groot probleem dat de telefooncentrale zelf niet is gedocumenteert.

Als je de header "Connection: Close" meestuurt wordt de verbinding wel gesloten.

[!null]

Je hebt helemaal gelijk, je vergeet alleen 1 klein detail. Deze telefoon centrale spuugt gewoon ruwe data uit en maakt helemaal geen gebruik van het HTTP protocol, gewoon platte tekst, helemaal geen headers. Anders konden we het idd netjes afsluiten.

Het wordt nog mooier, ik heb net ontdekt dat deze poort zelfs de CR en LF verkeerd om uitspuugt (dus LF -> CR).

(en ik weet genoeg van HTTP)

[ Voor 6% gewijzigd door !null op 16-04-2008 13:09 ]

[Niemand_Anders]

GreenSky schreef op woensdag 16 april 2008 @ 13:04:
Je hebt helemaal gelijk, je vergeet alleen 1 klein detail. Deze telefoon centrale spuugt gewoon ruwe data uit en maakt helemaal geen gebruik van het HTTP protocol, gewoon platte tekst, helemaal geen headers. Anders konden we het idd netjes afsluiten.

Het wordt nog mooier, ik heb net ontdekt dat deze poort zelfs de CR en LF verkeerd om uitspuugt (dus LF -> CR).

(en ik weet genoeg van HTTP)

Dan ben ik nu heel erg benieuwd naar de reden waarom curl gebruikt ipv een socket welke dan meer op zijn plaats zou zijn aangezien curl voornamelijk internet protocollen implementeert zoals http en ftp.

Van welke telefooncentrale maken jullie dan gebruik? Wij hebben tal van telefooncentrales (PBX-en) geimplementeert in intranets waaronder MDS Opera (aka KPN Vox Davo), Ayava, Asteriks en andere systemen.

[!null]

Ja cURL was misschien niet de juiste tool, maar van cURL weet ik dat de extensie al draait op de server (ok kleine moeite), en dat ik netjes een timeout kon opgeven. Het was meer zo van, wat kan ik snel in elkaar flansen. Want ik wil hier alleen even kijken wat de mogelijkheden zijn. (nu kan ik al alle info eruit halen wat ik nodig heb)

Met sockets (lezen met PHP_NORMAL_READ) werken was netter geweest, alleen moest ik dan zelf weer dingen inbouwen om na een vast aantal seconden er mee te stoppen (wat natuurlijk wel te doen is), want ik wil niet voor eeuwig doorgaan, het moet een cronjob worden.
Weet jij trouwens hoe ik met de PHP socket functies de grootte van de buffer kan uitvinden?

Het is een Vox Davo II. Ik heb trouwens 0 ervaring met telefooncentrales maar dit spreekt allemaal redelijk voor zich.

[ Voor 8% gewijzigd door !null op 16-04-2008 15:35 ]

[Patriot]

GreenSky schreef op woensdag 16 april 2008 @ 15:31:
Met sockets (lezen met PHP_NORMAL_READ) werken was netter geweest, alleen moest ik dan zelf weer dingen inbouwen om na een vast aantal seconden er mee te stoppen (wat natuurlijk wel te doen is), want ik wil niet voor eeuwig doorgaan, het moet een cronjob worden.
Weet jij trouwens hoe ik met de PHP socket functies de grootte van de buffer kan uitvinden?

Als ik het goed begrijp wil je die timeout omdat de telefooncentrale na verloop van tijd enkel geen relevante data meer geeft (alleen nog lege strings/newlines?), dan hoef je toch juist niet meer met timeouts te werken? Dan kun je gewoon kijken naar de laatst verkregen gegevens om te zien of de telefooncentrale nog relevante gegevens doorgeeft en als deze dat niet doet kun je de socket sluiten.

EDIT:

Overigens kun je mijns inziens beter PHP_BINARY_READ gebruiken aangezien de telefooncentrale CR én LF teruggeeft. Als je PHP_NORMAL_READ gebruikt zul je voor elke lijn twee keer socket_read() aan moeten roepen (bij PHP_NORMAL_READ stopt hij namelijk na het eerste newline character). bron

[ Voor 18% gewijzigd door Patriot op 16-04-2008 15:49 ]

[!null]

Nee het werkt niet zo. Hij geeft per telefoongesprek een soort van CSV regel, alleen dan verdeelt in 3 regels (met dus die CRLF's verkeerd om ertussen door). Verder houdt ie gewoon vrolijk de connectie open en blijft ie je nieuwe data sturen zodra iemand de telefoon erop gooit, is heel goed te zien m.b.v. Putty en een RAW sessie.
Dus je moet er zelf een eind aan knopen (teminste, gezien vanuit een PHP cronjob, een C++ applicatie als deamon zou netter zijn, en dan hoef je er geen eind aan te maken)

[Patriot]

GreenSky schreef op woensdag 16 april 2008 @ 15:48:
Nee het werkt niet zo. Hij geeft per telefoongesprek een soort van CSV regel, alleen dan verdeelt in 3 regels (met dus die CRLF's verkeerd om ertussen door). Verder houdt ie gewoon vrolijk de connectie open en blijft ie je nieuwe data sturen zodra iemand de telefoon erop gooit, is heel goed te zien m.b.v. Putty en een RAW sessie.
Dus je moet er zelf een eind aan knopen (teminste, gezien vanuit een PHP cronjob, een C++ applicatie als deamon zou netter zijn, en dan hoef je er geen eind aan te maken)

Wat voor data krijg je dan precies door op het moment dat het niet langer nodig is om de verbinding open te houden? Ik kan me namelijk niet voorstellen dat je de data niet op zo'n manier kan analyseren om te zien dat het niet langer nuttig is om de verbinding open te houden.

[ Voor 4% gewijzigd door Patriot op 16-04-2008 15:52 ]

[!null]

Geen data. Op de betreffende port werkt eigenlijk gewoon een buffer, die alle onthouden telefoongesprekken uitspuugt (3 regels per gesprek), is ie door alle aanwezige data heen dan stuurt ie letterlijk niks meer. Maar hij sluit de verbinding ook niet. En als je dan een nieuwe telefoongesprek gehad hebt, terwijl de connectie open staat, en je gooit de hoorn erop dan komt de info van dat telefoongesprek ook nog door.
En op die manier lees je dus eigenlijk de buffer uit, waardoor de telefooncentrale alles vergeten is (en dus weer een lege buffer begint te vullen).

[Patriot]

GreenSky schreef op woensdag 16 april 2008 @ 16:05:
Geen data. Op de betreffende port werkt eigenlijk gewoon een buffer, die alle onthouden telefoongesprekken uitspuugt (3 regels per gesprek), is ie door alle aanwezige data heen dan stuurt ie letterlijk niks meer. Maar hij sluit de verbinding ook niet. En als je dan een nieuwe telefoongesprek gehad hebt, terwijl de connectie open staat, en je gooit de hoorn erop dan komt de info van dat telefoongesprek ook nog door.
En op die manier lees je dus eigenlijk de buffer uit, waardoor de telefooncentrale alles vergeten is (en dus weer een lege buffer begint te vullen).

Dan kun jij toch gewoon stoppen als hij niets meer stuurt? Je hoeft toch niet te wachten tot de telefooncentrale de verbinding sluit, dat kun jij ook doen.

[ Voor 4% gewijzigd door Patriot op 16-04-2008 16:13 ]

[!null]

Dat is ook wat ik hierboven min of meer voorstelde. Maar hoe lees je de buffergrootte (niet de buffer van de telefooncentrale ) in php uit met socket functies? Want als ik die niet kan checken voor het readen betekent het dat ie op de laatste read hangt. Dus ik moet weten wanneer ik de communicatie moet sluiten voordat ik hang op een oneindige read (tot het volgende telefoontje).
Maar goed, ik heb ook nog niet eerder gewerkt met sockets en PHP samen.

[ Voor 16% gewijzigd door !null op 16-04-2008 16:21 ]

[Patriot]

Met socket_select() kun je kijken of er in de tijd dat je de socket_select() uitvoert iets nieuws te lezen valt op de socket. Je weet dan niet de grootte van de leesbuffer, maar je weet in ieder geval of er iets te lezen valt.

EDIT:

Voorbeeldje:

PHP:

<?php

// hier createn, binden en connecten

$r = array($socket);
$w = null;
$e = null;

do {
  if (socket_select($r, $w, $e, 0, 1) > 0) {
    // er kan gelezen worden zonder te blocken, doe iets
  } else {
    // er kan niets gelezen worden, kappen
    break;
  }
} while(true);

?>

Die tijdelijke variabelen met de null waarde zijn nodig omdat je geen null constante op kan geven in een functie die de parameter by reference verwacht.

[ Voor 53% gewijzigd door Patriot op 16-04-2008 16:37 ]

[!null]

Hee verdamd, er zit hier ook een select functie in. Ok, niet gezien sorry.
Dan is het idd goed te zien. Er bestaat in deze situatie alleen een kans dat je alleen een \r of \n uitleest maar niks wat je niet af kunt vangen.

Dit ga ik allemaal wel toepassen als er serieuze dingen mee gedaan gaan worden. Dankje.

[Niemand_Anders]

GreenSky schreef op woensdag 16 april 2008 @ 15:31:
Het is een Vox Davo II. Ik heb trouwens 0 ervaring met telefooncentrales maar dit spreekt allemaal redelijk voor zich.

De Vox Davo heeft standaard al een webinterface op poort 7000. Zie screenshot:

[!null]

je plaatje doet het niet helaas.
Ik ben wel in de webinterface geweest (ik dacht gewoon op port 80 maar weet niet zeker maar) wat eruit zag als startpagina.nl (die blokjes menu indeling), waar ik ook een lijst met interresante poort nummers kon opvragen. Ik neem aan dat we het over dezelfde interface hebben?

[Niemand_Anders]

Yep, da's de interface. Maar wat probeer jij dan nu met curl te doen wat niet met de default webinterface van de vox davo kan?

Vreemd trouwens dat het plaatje niet werkt. Ik zal het thuis eens nakijken

[!null]

Ik weet nog niet alles van die webinterface, maar mijn doel is om geautomatiseerd telefoongesprekken te laten ophalen, om deze te loggen in een database. Zodat de telefoongesprekken voor altijd onthouden worden (wat de Vox Davo niet lijkt te doen (logisch)) en het eventueel integreren in ons bestaande systeem, of rapportages van te maken.

[Verwijderd]

Bij de meeste telefooncentrales is het niet de bedoeling dat de interface die de call accounting / call charging gegevens afvangt de verbinding verbreekt, ze zijn meestal doorontwikkeld van seriele communicatie naar TCP/IP, en zien de uitgaande poort dan ook ongeveer als een veredelde printer die altijd staat te luisteren. Vandaar vaak ook nog de <STX> en <ETX> karakters en CRC in 't protocol, ook al is dat bij TCP/IP nogal overbodig.
Extreem voorbeeld is een Siemens Hicom 300, de hele PABX moet herstart worden wanneer de communicatie met de interface meer dan 5 minuten afwezig is geweest...

Nieuwere centrales hebben vaak ook een management mogelijkheid waar je als je geluk hebt ook gespreksgegevens kunt opvragen, en die zijn meestal wel van het type connect -> authenticate -> gegevens ophalen -> disconnect gracefully. Dan is cURL wel aardig te gebruiken, al is 't wel een zwitsers zakmes gebruiken terwijl 't met een simpele schroevendraaier (socket) efficienter kan.

Voor zover ik kan zien gaat 't bij jouw implementatie puur om call accounting, en dan lijkt me cURL en een cronjob niet handig. Ik zou eerder kiezen voor een deamon / background job die continu met de socket van de PABX communiceert en die gegevens in de database plempt.
En dat kan prima in PHP, daar hoef je niet naar C++ voor uit te wijken.

(ik schrijf software voor hotels en hotelketens, en heb de afgelopen 10 jaar al een hoop interfaces met PABX's (mede-)ontwikkeld, en ik zou me niet op m'n gemak voelen wanneer een collega zou besluiten om hier cURL voor te gebruiken...)

[Niemand_Anders]

Ik denk dat je het beste even kunt inloggen op de vox davo en dan even bij 'IP Loggins' uit 'Router instellingen' kunt kijken. Een van de poortnummers welke je kunt bekijken c.q. instellen is 'Call logging'.

Telnet vervolgens maar eens naar het IP van je centrale en de betreffende call logging port. Je hebt dan alle informatie in CSV formaat welke je nodig hebt zoals gebruikt toestel, start datum, gesprekduur, gebeld nummer, etc. Deze socket kun je continue uitlezen of periodiek. Elke regel wordt vooraf gegaan van een logid. Let op. Over deze socket wordt een gesprek eenmalig doorgegeven..

[FragFrog]

Verwijderd schreef op donderdag 17 april 2008 @ 20:52:

Voor zover ik kan zien gaat 't bij jouw implementatie puur om call accounting, en dan lijkt me cURL en een cronjob niet handig. Ik zou eerder kiezen voor een deamon / background job die continu met de socket van de PABX communiceert en die gegevens in de database plempt.
En dat kan prima in PHP, daar hoef je niet naar C++ voor uit te wijken.

Precies, PHP in CLI mode kan ook gewoon continue runnen, gebruik je dan socket_select om te wachten op nieuwe data ben je in principe al half klaar: socket openen, socket_select erop, als er data is lees je die in, daarna gaat'ie weer automatisch wachten.

Enig puntje daarbij is dat je database connectie automatisch gesloten kan worden als je te lang niets stuurt (als je script bijvoorbeeld een nacht lang niets doet) dus daar zul je een extra check op moeten zetten danwel een no-timeout als je het als daemon implementeert

Weet niet wat voor OS je server draait trouwens, maar met firedaemon kun je erg simpel een PHP script als windows service laten runnen, wellicht nuttige info.

[ Voor 9% gewijzigd door FragFrog op 18-04-2008 14:51 ]

[Niemand_Anders]

Enig puntje daarbij is dat je database connectie automatisch gesloten kan worden als je te lang niets stuurt (als je script bijvoorbeeld een nacht lang niets doet) dus daar zul je een extra check op moeten zetten danwel een no-timeout als je het als daemon implementeert

Je moet per definitie geen database verbindingen open houden als dat niet nodig is. Je open de verbinding net voordat je de query uitvoert en zodra je het resultaat hebt, sluit je deze weer netjes. Dat heet resource management. Maar dat behoort wat mij betreft tot de basis kennis van een programmeur.

Hoeveel websites ik niet plat heb zien gaan omdat je een database connectie openen aan het begin van de page en pas aan het einde weer sluiten. DDOS attacks zijn op die manier wel heel erg simpel. Want vaak is er geen database verbinding nodig, omdat alle informatie uit de cache komt.

Meer ontopic. Het is voor een phonelog applicatie niet nodig dat deze continue draait. De Vox Davo wordt over het algemeen bij de wat kleinere bedrijven gebruikt (tot 14 toestellen zijn mogelijk). Dus is periodiek uitlezen van de log queue meer dan voldoende. Wij lezen de Vox Davo's slechts elke half uur uit. Alleen als we een centrale hebben opgeleverd, dan hangen we een 'monitor' applicatie aan de debugging porten.

[FragFrog]

Niemand_Anders schreef op vrijdag 18 april 2008 @ 16:45:
Je moet per definitie geen database verbindingen open houden als dat niet nodig is. Je open de verbinding net voordat je de query uitvoert en zodra je het resultaat hebt, sluit je deze weer netjes. Dat heet resource management. Maar dat behoort wat mij betreft tot de basis kennis van een programmeur.

Voor een beetje site betekend dat al snel 20 ~ 30 connecties openen en sluiten voor elke pageview. Dan is een connectie gebruiken en openhouden een stuk efficienter. Sterker nog, op die manier kun je juist simpeler een DDOS aanval openen omdat een SQL server veel eerder dan een webserver over z'n nek zal gaan door teveel connecties - zeker als je bedenkt dat voor elke webserver connectie er soms tientallen DB connecties nodig zijn.

Voor een daemon is het een ander verhaal, maar dan nog zou ik de connectie pas sluiten na een minuut inactiviteit ofzo. Resource management is ook weten wanneer je beter een persistent connectie kunt gebruiken.

[!null]

Niemand_Anders schreef op vrijdag 18 april 2008 @ 13:52:
Ik denk dat je het beste even kunt inloggen op de vox davo en dan even bij 'IP Loggins' uit 'Router instellingen' kunt kijken. Een van de poortnummers welke je kunt bekijken c.q. instellen is 'Call logging'.

Telnet vervolgens maar eens naar het IP van je centrale en de betreffende call logging port. Je hebt dan alle informatie in CSV formaat welke je nodig hebt zoals gebruikt toestel, start datum, gesprekduur, gebeld nummer, etc. Deze socket kun je continue uitlezen of periodiek. Elke regel wordt vooraf gegaan van een logid. Let op. Over deze socket wordt een gesprek eenmalig doorgegeven..

Die port gebruik ik dus al de hele tijd Staat bij ons op 5070 (waarschijnlijk de standaard waarde)

Maar goed, we zijn het allemaal eens dat cURL niet het beste hier voor is. En de hele PHP socket library wel beter is, zeker met die select functie.

Verder zie ik het liever wel als een cronjob die zo af en toe draait. Het hoeft niet de hele tijd te draaien (zo 'realtime' hoeft het niet), en zou dat wel moeten dan had ik wel wat met C++ en een deamon gedaan.

[Niemand_Anders]

Waarom heb je dat dan niet in je topic vermeld? Je had het over een brakke html implementatie en een ieder die weleens met de vox davo heeft gewerkt zal direct denken aan de html interface van de vox davo zelf en niet dat jij probeert CSV regeltjes vanaf een TCP poort probeert te verwerken.

Maar ik snap nu ook precies waarom jij met curl op een timeout moet wachten. Poort 5070 is een minitor poort en zal nooit zelf de verbinding verbreken tenzij de centrale zelf wordt herstart..

Bij de meeste bedrijven waarbij wij de vox davo hebben geintregreerd lezen we deze socket elke 4 uur uit. Daarbij lezen we net zoalng de socket minder terug geeft dan er in de buffer past (length argument). En daarna sluiten we de connectie.

[!null]

GreenSky schreef op woensdag 16 april 2008 @ 11:08:Echter heeft de telefooncentrale geen nette http implementatie met afsluiting etc, nee het is gewoon rauwe data en hij laat je eeuwig wachten om je steeds de laatste info door te geven. (verbinden lukt wel meteen, dus in die zin geen timeout)

Leek me vrij duidelijk, ik heb het iig nooit over een brakke html implementatie gehad. Je verzint er steeds dingen bij (net als met die HTTP headers)

Daarnaast begon ik het topic ook met insteek hoe deze situatie op te lossen in PHP, dat het een telefooncentrale was was minder belangrijk. Maar goed, heb het dus allang aan de praat, en weet hoe het (netter) moet.