( igoor | 2013. 03. 22., p – 18:19 )

Szoval nehez, latom ...

Most mondok valami sokkolot. Nincs socket, nincs UDP datagramm. Az mar az implementacio resze. A kuldo szamara van egy Service Access Point egy nem megbizhato atvitelt nyujto protokoll reteghez. Ez megvan? Vagy ismeteljem? OK, akkor menjunk tovabb ... Itt vagy mar? Jo, varok. ... Semmi gond, a lenyeg, hogy megertsd. Tehat, mivel a szolgaltatas nem megbizhato, az egvilagon semmi ertelme nincs a szolgaltatas igenybevevojenek egy "al-nyugtat" visszaadni. De legyunk egy kicsit konkretabbak es vegyuk a syslog-ot, mint peldat. Egy jobb sorsu syslog bejegyzes kb. ilyen utat tehet meg (van tobb lehetoseg is, de maradjunk most ennel): Originator/Device-->Relay 1-->...Relay N-->Collector

Neked az a velemenyed, hogy ha az elso lepes sikerult, akkor minden rendben van. Nagy hiba! Es ha az alkalmazasod barmifele modon is felhasznalja az adott implementaciotol (legyen az PHP, vagy egyeb mas szutyok) igy visszakapott informaciot, akkor az alkalmazas el van qrva! Nem kicsit, nagyon! Ugyanis ha neked feltetlenul szukseged van egy _megbizhato_ nyugtara, akkor arra vannak olyan megoldasok, ahol az atvitel is megbizhato, ha viszont a nyugta, nem is igazi nyugta, akkor mi a fenenek kell?

Ha ezt sikerult felfogni, amit az elozmenyek ismereteben erosen ketlek, akkor azt is megerted, hogy mekkora faszsagokat hordtal itt ossze a kis listaddal. Egyebkent felelmetes mennyire nincs absztrakcios keszseged, eleg ha mar a legelso peldadat vesszuk: NOT_ENOUGH_MEMORY -> Nem ittal elegendot ahhoz, hogy lepisalj az erkelyrol
A pisad maga a payload, ha nincs, mit akarsz a SAP-on keresztul igenybe venni? Mi koze van ennek a szolgaltatashoz? De a tobbi legalabb ugyanilyen baromsag ...