[PHP] Usenet server ontvangt data niet goed (fwrite)

[Reddol]

Ik moet voor een niet nader te noemen website een NZB bestand (in feite gewoon XML) geëncodeerd naar een usenet server sturen, hiervoor moet het volgende gebeuren:
- NZB Bestand deflaten (gzdeflate)
- Gedeflate informatie encoden (= => =D, \n => =C, \r => =B, \0 => =A)
- Geëncode informatie naar usenet sturen

Het deflaten en encoden zelf gaat zonder problemen. Wanneer ik deze data in een variabele bewaar en daarna decode en inflate heb ik weer het originele NZB bestand, hier gaat dus niets mis.
Het verzenden naar het usenet gaat ook, het usenet geeft aan dat het bestand "geupload" is, en dat alles succesvol afgehandeld is.

Wanneer ik echter de informatie van de usenet server afhaal is er een probleem: de data is niet wat het origineel was. Het vreemde hiervan is dat de data wel gedecode en geïnflate kan worden, hierbij ontstaan geen errors. Maar nadat het geïnflate is ontstaat er een andere uitkomst dan het originele bestand. De eerste 40 / 50% is gewoon hetzelfde, en daarna staat het door elkaar heen.

Dit gebeurd alleen bij bestanden met een aardige inhoud, zeg boven de 1MB (originele data). Kleinere bestanden kunnen na het proces wel correct van de usenet server worden opgehaald.

Ik snap niet waar het hier misgaat, en ik ben benieuwd of jullie ideeën hebben. Het verzenden naar het usenet gaat met een eigen gemaakte class. Hetgeen hierin gebeurd is redelijk simpel:
- Er wordt een stream (/ file pointer) geopend met de functie stream_socket_client (of fsockopen)
- Er worden commando's naar de usenet server gestuurd met de functie fwrite
- De status die de usenetserver terugstuurd wordt vervolgens afgevangen met fgets

Wanneer de geëncodeerde data verstuurd wordt maak ik hier eerst pakketten van 911 characters lang van, Dit d.m.v. de functie chunk_split. De lijnen worden dus netjes gescheiden met een newline (\n).
Vervolgens stuur ik dit met een fwrite naar de usenet server, en check de status. De return waarde van de fwrite functie geeft altijd aan dat alles verzonden is, en er geen fouten zijn opgetreden.

Ikzelf dacht dat dit had te maken met de fwrite functie die bepaalde characters misschien niet aankon, dus heb ik het geprobeerd te schrijven naar een tekstbestand, dit ging prima. Hierna kon ik ook gewoon het tekstbestand decoden en inflaten. En het originele bestand kwam weer tevoorschijn. Het lijkt hier dus te liggen aan de data-overdracht tussen mijn server en de usenet server.

Ook niet onbelangrijk: Ik heb al geprobeerd om het meerdere posts op het usenet te zetten, om vervolgens alles bij elkaar te voegen en dan te bekijken of de data wel goed is. Kleinere pakketten dus. Dit helpt echter ook niet, de uiteindelijke data is dan voor 70/80% goed, maar de laatste paar honderd lijnen staan ook door elkaar heen.

Ik zal hier hopelijk iets over het hoofd zien, en hoop dat jullie mij kunnen helpen. Als ik in iets onduidelijk ben geweest hoor ik het wel! Stukken van de source zijn in principe ook in te zien, laat maar weten welk stuk er nodig is. Vanwege het probleem dacht ik dat het niet zo nodig was om dit nu al bij te voegen.

---

Bijlagen:
Goede NZB data

code:

<file poster="[e-mail]" date="1326116663" subject="Laatste Ubuntu">
<groups>
<group>alt.binaries.boneless</group>
</groups>
<segments>
<segment bytes="258454" number="1">[e-mail]</segment>
<segment bytes="257964" number="2">[e-mail]</segment>

NZB Data die door elkaar staat (voorbeeld)

code:

<groups>
<group>alt.binaries.114eless</group>
</groups>
<segments>
<segment bytes="258030" number="1">[e-mail]</sment>
<ff0ment0503ms="258354e334b76r="105">[e-mail]</2ment>
<ff1ment0503ms="258354e334b76r="105">[e-mail]</3ment>

[ReenL]

Undo je wel de chunk split bij het ophalen. Blijkbaar krijg je de binairy data van je usenet provider in een bepaalde encoding terug die niet veel verschilt van het origineel.

Een ander probleem kan zijn dat de server je chunk split niet goed begrijpt, vervolgens de data zelf nog eens split en dat je dus een chunk split te weinig heb.

Verder niet veel verstand van het protocol, wat ik wel weet is dat je ook met retentie te maken hebt. al geprobeert met PHP iets te uploaden en dan met een echte newsreader uit te lezen, dan kun je namelijk vaststellen of de fout in het lezen of in het schrijven ligt.

[Reddol]

Hoi, ik werk volgens het Spotnet "protocol", en het moet dus in meerdere tools toegankelijk zijn. Hierbij is de regel dat het lijnen rond de 900 chars zijn, en die worden in elk programma ook weer aan elkaar gezet. Zo ook in mijn website.

De chunk split begrijpt de server, dit heb ik gecheckt. Ook hiervoor heb ik al meerdere functies gebruikt. (B.v. str_split en vervolgens geloopt en per lijn weggeschreven). Dus hier ligt het helass ook niet aan.

Met de retentie zit het ook goed, ik zet het er namelijk op met een payserver, en lees het uit met diezelfde payserver, hiertussen zitten nog geen uren, en de server kan 100'en dagen aan. Andere newsreaders geven exact hetzelfde resultaat.

[ValHallASW]

Reddol schreef op woensdag 11 januari 2012 @ 20:00:
- Gedeflate informatie encoden (= => =D, \n => =C, \r => =B, \0 => =A)

Zoals je het nu opschrijft lijkt het alsof je alleen die tekens hebt geïmplementeerd. Dat /zou/ OK moeten (kunnen) zijn zolang je alleen XML stuurt, maar toch. Waarom gebruik je niet gewoon een standaardlibrary (het is yenc, toch?) om te zorgen dat alle 7-bits-meuk het niet verandert?

Heb je ook rekening gehouden met de rest van de yenc-spec, inclusief alle =ybegin-grappen?
http://www.yenc.org/yenc-draft.1.3.txt

Dan eigenlijk een algemene vraag: waarom interface je niet gewoon met een bestaande usenetposter? Daar zijn dit soort bugs allang uitgehaald, zodat je je kunt concentreren op het nuttige deel (nl. het interfacen met de website en eventueel de gzdeflate).

[ Voor 9% gewijzigd door ValHallASW op 12-01-2012 09:35 ]

[Reddol]

Alleen die tekens zijn inderdaad geïmplementeerd, is ook niet mijn idee. Zoals ik zei zit ik vast aan een bestaand "protocol" (spotnet), en kan ik dit dus niet veranderen. Het is geen yEnc, helaas.

Interfacen met een bestaande usenetposter zou mooi zijn, maar die zijn maar zeer beperkt beschikbaar. En als ze al te vinden zijn voor PHP is het simpelweg oud. Ik zal het PEAR pakket net_nntp eens onderzoeken, die ondersteund namelijk wel schrijven naar het usenet, maar daar is helaas 0 documentatie van.

[ValHallASW]

https://github.com/spotwe...r/lib/SpotPosting.php#L83

Hoe ze het encoden daar aanpakken kan ik zo 1-2-3 niet terugvinden, maar in ieder geval is het een kant en klare library om te doen wat je wilt. en hij stond gewoon op wikipedia genoemd

[ Voor 11% gewijzigd door ValHallASW op 12-01-2012 12:39 ]

[Reddol]

Ja, dit is een leuke spotweb code ja, die ga ik niet gebruiken. Ikzelf vind het een beetje spaghetti-code, en het gaat niet lukken om 1-2-3 die code over te nemen, want het zit door het gehele script verwerkt.

Spotweb maakt wel gebruik van de net_nntp lib, dus ik zal daar eens naar kijken. Bedankt.

[Reddol]

Zojuist het script aangepast zodat er gebruik wordt gemaakt van de Pear lib Net_NNTP. Ook dit zonder resultaat. Het resultaat van het bestand dat op het usenet wordt gezet is exact hetzelfde: het laatste gedeelte is weer gehusseld. Iemand nog ideeën?

Edit
Waarschijnlijk lag het aan de server, na een andere server gebruikt te hebben werkt het wel.
Voor nu opgelost, maar het blijft in mijn ogen een vreemde zaak...

[ Voor 26% gewijzigd door Reddol op 13-01-2012 21:57 ]