[PHP-CLI] Bi-directionele socket connectie

[cappie]

Probleemstelling:

Ik wil een listening daemon maken die poort connecties accepteert en vervolgens bij een openstaande poort verbinding gegevens kan pushen en kan ontvangen (maar dan wel tegelijkertijd)...

Wat ik nu al heb is een listening socket met een simpel handshake dingetje waarmee de andere kant informatie kan versturen en kan ophalen, maar... (en nou komt het).. ik wil eigenlijk nog een 2e subthread aanmaken die iedere 500 milliseconden een query op een database loslaat (wat natuurlijk lekker gecached is voor snelheid) en die (bij het zien van nieuwe records in de output tabel) de data verstuurt.

Hoe kan ik een 2e thread maken die (zodra er iets in de output tabel staat) meteen deze data uitspuugt.. OOK AL STAAT DE 1STE THREAD TE WACHTEN OP INPUT.. (want daar loop ik nu vast, outputten gaat niet als je nog op input staat te wachten).

Als ik hem nu opstart (vanaf de linuxconsole), doet 'ie dit: (zoals het hoort, zie source)

code:

[e-mail]:~/listener$ php ./listen.php
SERVICE LISTENING ON 0.0.0.0:1337
[e-mail]:~/listener$

De database (voor diegene die dit willen testen) bestaat uit 2 tables, 'input' & 'output', met beide een 'id' en een 'data' veld. .. eventjes de connection parameters aanpassen en dan kun je 't zelf ook draaien eventueel.

id	int
data	text
created	timestamp

Hieronder m'n broncode:

*snip*

[ Voor 73% gewijzigd door MueR op 30-03-2011 14:54 ]

[MueR]

Ik heb die 350 regels code even weggehaald. We zien liever alleen het relevante stuk code waar je probleem in zit. Nog afgezien van het vermoeden dat je deze code ergens op het internet hebt gevonden (support op third party software mag in eerste instantie bij de auteur), is 350 regels code gewoon onzinnig voor ons.

[Keiichi]

Is er een rede waarom je dit in PHP wilt doen?

In perl heb ik in groffe lijnen wel zoiets weten te maken. Maar het verdient absoluut geen schoonheidsprijs.

[cappie]

MueR schreef op woensdag 30 maart 2011 @ 14:55:
Ik heb die 350 regels code even weggehaald. We zien liever alleen het relevante stuk code waar je probleem in zit. Nog afgezien van het vermoeden dat je deze code ergens op het internet hebt gevonden (support op third party software mag in eerste instantie bij de auteur), is 350 regels code gewoon onzinnig voor ons.

Jah, en bedankt.. allereerst heb ik het zelf geschreven aan de hand van voorbeelden en werkt het prima.. verder vind ik het erg jammer dat je als mod maar meteen weer allerlei aannames doet... tevens werkt mijn code prima en zou het eventueel handig kunnen zijn voor anderen... hopelijk zie je dit in en corrigeer je de door jou gemaakte fout.

Het hele probleem zit niet in mijn code, maar het feit dat ik niet weet hoe ik, tijdens het luisteren naar incoming data _OOK_ kan outputten via dezelfde socket naar de andere kant.. net zoals een telnet verbinding dus...

Ik ben dus op zoek naar iemand die wellicht zin heeft om mij uit te leggen hoe ik zoiets zou kunnen aanpakken, vooral omdat ik niet weet waar ik naar moet zoeken online.. de voor de hand liggende zoektermen leveren me niets op.

[cappie]

Keiichi schreef op woensdag 30 maart 2011 @ 14:59:
Is er een rede waarom je dit in PHP wilt doen?

In perl heb ik in groffe lijnen wel zoiets weten te maken. Maar het verdient absoluut geen schoonheidsprijs.

Mijn Perl ervaring beperkt zich tot wat truukjes met strings en regular expressions.. nooit echt iets gedaan wat listening sockets maakt en gebruikt, vandaar dat ik PHP heb gekozen.

Ik heb 't nu ook al zo dat m'n main thread netjes luistert naar incoming connections en bij aankomst de client direct naar een subthread waar alle verdere communicatie afgehandeld wordt, maargoed..
*niet in het topic klagen over moderaties*

[ Voor 5% gewijzigd door MueR op 30-03-2011 15:22 ]

[B-Man]

Wat is nu precies je vraag? want los van de broncode klinkt het alsof je al in staat bent om met threads te werken en met sockets. Wil je een tweede thread op je socket laten werken, dan start je een tweede thread die je de socket meegeeft, misschien wat locking en klaar is cappie?

[Keiichi]

Maar als het 350 lijnenzijn, doet het dan niet heel wat meer dan we nu geintresseerd in zijn? Post het anders op pastbin.com oid.

[ Voor 3% gewijzigd door Keiichi op 30-03-2011 15:12 ]

[cappie]

Modbreak:

*nee, ook niet op pastebin. je mag hier best code posten, maar alleen het relevante deel. 350 regels code is niet iets wat wij voor je gaan debuggen. Zie Devschuur® Beleid - Hoe post je code?

Voor zover ik weet kun je na de hand-off niet weer (op een tweede subthread) een socket connectie openen naar de reeds geconnecte client.. of heb ik het mis en kan dit via de parent thread en/of een andere manier?

[ Voor 112% gewijzigd door MueR op 30-03-2011 15:21 ]

[CodeCaster]

Je wil dus asynchroon werken?

[Keiichi]

Je werkt overigens niet met threads, maar het forks. Een wereld van verschil.

[cappie]

Keiichi schreef op woensdag 30 maart 2011 @ 15:25:
Je werkt overigens niet met threads, maar het forks. Een wereld van verschil.

Jah, forks.. maar aparte threads op het systeem toch.. of begrijp ik het nou verkeerd?

Wat is het verschil in dit geval?

[cappie]

CodeCaster schreef op woensdag 30 maart 2011 @ 15:24:
Je wil dus asynchroon werken?

JAH! cool.. thnx!

erhm.. nee.. dit is op basis van polling.. en dat probeer ik nou juist te omzeilen.. wat ik nu heb geschreven is polling-based.. de client die op mijn socket connect kan data opvragen en pushen, maar ik kan tijdens het luisteren niets terugschrijven omdat m'n script alleen maar op input en een \r, \n of \r\n staat te wachten.

Het is vergelijkbaar met POP3.. je luistert, daarna voer je iets uit, output je het, en luister je weer.. het is niet zo (bij een open POP3 verbinding) dat de client ineens een UPDT (update) melding krijgt met daarin de content van de mail (RETR #) of een nieuwe LIST.

[ Voor 57% gewijzigd door cappie op 30-03-2011 15:33 ]

[B-Man]

Een fork levert een nieuw proces op ipv een thread. Een thread is lichter dan een proces.

De kortste weg met je huidige code lijkt om 2 subprocessen te forken, al loont het om eens te kijken of je dit niet in een andere taal kunt oplossen. Ik heb lang geleden ook eens gewerkt met php toen ik begon met (server-) socket programming, maar ben vrij snel overgestapt op Java. PHP kan vanalles maar is hier niet op zijn sterkst vind ik.

In Java, .Net, python, perl, enz kun je relatief eenvoudig met echte threads werken en loop je ook niet tegen mogelijke issues met forking aan.

[cappie]

B-Man schreef op woensdag 30 maart 2011 @ 15:34:
Een fork levert een nieuw proces op ipv een thread. Een thread is lichter dan een proces.

De kortste weg met je huidige code lijkt om 2 subprocessen te forken, al loont het om eens te kijken of je dit niet in een andere taal kunt oplossen. Ik heb lang geleden ook eens gewerkt met php toen ik begon met (server-) socket programming, maar ben vrij snel overgestapt op Java. PHP kan vanalles maar is hier niet op zijn sterkst vind ik.

In Java, .Net, python, perl, enz kun je relatief eenvoudig met echte threads werken en loop je ook niet tegen mogelijke issues met forking aan.

Hmm.. Java dan maar... damn.. ik had zo gehoopt dat 't binnen PHP op te lossen was.. maargoed, thnx voor je tip & uitleg!

[ReenL]

Waarom moet alles in losse threads?

Je kunt ook alles in 1 proces doen, maar dan moet je de functies wel op non-blocking modus zetten.

code:

while ( running ) {
    executeCachedQuery();
    for ( $i = 0 to 5 ) {
        connectWithClient();
        handleClients();
        usleep(10000);
    }
}

Als je nu zorgt dat het handlen van clients en de query cache niet al te lang duurt dan kan dit prima performen en kun je ongeveer 10 clients per seconde aan.

[cappie]

ReenL schreef op woensdag 30 maart 2011 @ 22:48:
Waarom moet alles in losse threads?

Je kunt ook alles in 1 proces doen, maar dan moet je de functies wel op non-blocking modus zetten.

code:

while ( running ) {
    executeCachedQuery();
    for ( $i = 0 to 5 ) {
        connectWithClient();
        handleClients();
        usleep(10000);
    }
}

Als je nu zorgt dat het handlen van clients en de query cache niet al te lang duurt dan kan dit prima performen en kun je ongeveer 10 clients per seconde aan.

Zo eens even wat mee testen zodra ik op kantoor ben...