Forgalomkorlátozás + felhő problémakör

[EPluribusUnum]

A forgalomkorlátozás az betesz a felhőszolgáltatásnak. Több száz cég fut egyetlen IP alatt és az egyes cégek egymástól függetlenül szolgáltatnak adatot, nem tudnak egymásról. Ezzel a szűréssel viszont valahogy koordinálni kellene már a NAV felé a kommunikációt a cégek között, ami horror. Az IP alaú szűrés az kevés, valahogy IP + adószám alapján kellene korlátozni.

[NTCA-developer]

Szia @EPluribusUnum

Az miért probléma, hogy csak a v2-es státusz lekérdezések késleltetve vannak? Az esetleges kitiltás is csak a státusz lekérdezést érinti. Adatszolgáltatás beküldését ez a szűrés nem fogja meg.

[peterkulik]

Infó mindenképpen kellene, hogy mi lesz a működés. GeneralError, vagy csak a szerver elutasítja a kérést? Jó lett volna ezt a teszten kipróbálni, mert le kellene kezelni ezt az állapotot. Holnap meg már élesben megy ez a fajta működés, leírás meg, ha jól látom nincs frissítve.

[NTCA-developer]

Hamarosan a teszten is ki lehet próbálni. Egyébként ez layer3 működés, szóval oprendszertől függ hogy mit fogsz látni. De az mindenképpen közös, hogy valamilyen connection reset lesz. Erre viszont szerintem mindenki fel kell hogy legyen készülve, alap try-catch működés.

[omachtandras]

Szia @EPluribusUnum

Az miért probléma, hogy csak a v2-es státusz lekérdezések késleltetve vannak? Az esetleges kitiltás is csak a státusz lekérdezést érinti. Adatszolgáltatás beküldését ez a szűrés nem fogja meg.

Sziasztok!

Mi a helyezte mondjuk egy közüzemi szolgáltatónál, aki egy számlázási pillanatban akár 100.000 olyan számlát is érvényesít január 1-től (magánszamély), amelyet be kell küldeni. Ezek a beküldések egy ip címről fognak megtörténni, és mivel nincs erre az ágra korlátozás, ezért "azonnal be is fognak menni" A lekérdezés is ugynarról az ip címről történik majd, de ott már meglesz a korlátozás. A 100.000 lekérdezés 100.000 mp-et fog igényelni?

Nálunk olyan az infrastruktúra, hogy erről az ip címről párhuzamosan több száz olyan céggel kapcsolatban is indul(hat) lekérdezés, amelyek 1-1 számlát állítanak ki egy adott pillanatban, de ha jól értem, akkor ők mostantól konkurensek lesznek (a NAV szempontjából), tehát rossz esetben nekik is meg kell várni a 100.000 mp-et, mire sikeresen választ kaphatnak az egyetlen számlájukra

Értem az alap problémát, ami miatt a korlátozás mellett döntöttetek, de jelenleg bizonytalan vagyok, hogy ez a mi infrastruktúránkban milyen következményekkel jár. (A sikertelen lekérdezések logolásra kerülnek, nem örülnék, ha több tíz vagy százezer log rekordunk lenne ez miatt.)

[NTCA-developer]

@omachtandras

A közüzemi szolgáltatók kötegelve küldenek, tehát oszd el százzal a kéréseik számát.

[omachtandras]

Lehet, hogy úgy küldik, de mi biztosan nem. És ez nem is volt előírás soha, hogy kötegelten kell küldeni. Hogy miért történt ez a döntés annak idején, azt nem szeretném részletezni, jogászokkal történt egyeztetés, stb., de ez adottság, és nem is hiszem, hogy középtávon ezen változtatni fognak / fogunk. De, ha kötegelten is menne, akkor is 1.000 kötegről beszélünk.

[EPluribusUnum]

Szia @EPluribusUnum

Az miért probléma, hogy csak a v2-es státusz lekérdezések késleltetve vannak? Az esetleges kitiltás is csak a státusz lekérdezést érinti. Adatszolgáltatás beküldését ez a szűrés nem fogja meg.

Az adatszolgáltatás teljesítéshez a queryTransactionStatus-nak DONE-t kell visszaadnia, és pont azt korlátozzátok le. Ráadásul olyan limitet adtatok meg ami nem cég szintű, így koodinálni kell a cégek közötti lekérdezést, hogy ne fussanak egymásra a hívások, ne kezdjenek növekedni a késleltetések. A hír szerint minden egyes egymásra futás további +4sec-el növeli a késletetést, és koordináció nélkül így potenciálisan nagyon gyorsan meg tud hízni a késletetés.

• Van még az eset amikor egy cég állít ki tömegesen számlát, még csak felhő sem kell. Akkor ott is minden egyes számlához 1 sec-es várakozást kellene beépíteni a lekérdezések közé fixen, hogy ne legyen probléma?

[szako]

@NTCA-developer Az újraküldés időpontját a válasz visszaküldésétől vagy az eredeti kérés küldésétől számítja a rendszer? Ha szinkron fut egy process és mindenképp megvárja az első 4 másodperces késleltetést, a következő küldés várakoztatva lesz vagy befogadja a rendszer?

[NTCA-developer]

@omachtandras, @EPluribusUnum Ha jól számolom, akkor 1 másodpercen belüli időablakot nézve a másodiktól indul a késleltetés, tehát egy sec alatt egy forrás IP-ről 15+1 párhuzamos lekérdező szálat tudsz fenntartani. Szerintem ez az elégségesnél bőven több, igaz, hogy a válaszidő lineárisan egyre magasabb lesz. Lássuk meg hogy mit hoz az élet. Az azonnaliság követelménye a beküldésre vonatkozik, a lekérdezésre nem, ezért async a működés. Ha egy nap múlva dolgozzuk csak fel a számla adatokat, akkor egy nap múlva kaphattok csak választ. Semmiféle problémát nem látunk ezen a téren, hogy nem azonnal, hanem X perc múlva kapjátok csak meg a feldolgozási eredményt.

@szako

Másodpercenkénti ablakokat vizsgálva már a második beérkező státusz lekérdezés elindítja a késleltetést. Ennek a lehűlési ideje a max késleltetés időtartama, tehát legfeljebb 1 perc után mindig tiszta lappal indulsz.

[nbeeps2]

@NTCA-developer : egyáltalán nem támogatom ezt a működést! Célzottan vegyétek fel a kapcsolatot az érintett fejlesztő cégekkel, akik miatt erre az intézkedésre szükség volt!

[nbeeps2]

Az meg végképp elfogadhatatlan, hogy élesben ez csak úgy bumm belekerül, anélkül, hogy erre fel lehetne készülni. A teszt rendszerben kellett volna ez betenni, hogy mindenki le tudja tesztelni, hogy ez a korlátozás hogy érinti a saját programját. Utána időt hagyni az átállásra és ezt követően élesíteni...

[NTCA-developer]

@nbeeps2 és mi erre a konkrét indok? Ismételni nem akarom magam, de ez semmilyen jóhiszeműen működő adózót vagy számlázó programot nem befolyásol hátrányosan.

[szako]

@NTCA-developer Csak arra akarok kilyukadni, hogy ha minimális késleltetéssel (pl. 0,1s) működik jelenleg a rendszer kliens oldalon jelenleg és egy process küldi be a számlákat (a párhuzamosítást kikapcsoljuk), akkor az élesítés után 4 másodpercre fog változni beküldések közötti időtartam?

[csaszko]

Van még az eset amikor egy cég állít ki tömegesen számlát, még csak felhő sem kell. Akkor ott is minden egyes számlához 1 sec-es várakozást kellene beépíteni a lekérdezések közé fixen, hogy ne legyen probléma?

Lehet, hogy nem lesz rá példa.. de.. ha egy külső IP-t több/sok cég használ (pl. wifis-s,( de telekom is csinálja..szóval.) szolgáltató natol és nincs külön ip) és egyszerre indítanak, akár tömeges számlázást, akár csak szeretné tudni, hogy mi milyen státuszban van mert ki volt tiltva pénteken és hetfő reggel indítják újra 8 kor a gépeket.... Ebben az esetben aztán optimalizálhatsz kliens oldalon bármit.. nem is tudsz róla, hogy adott IP miért van tiltva és folyamatosan összeakadnak a lekérdezések.

[nbeeps2]

@NTCA-developer : csaszko épp most fogalmazta meg. IP cím alapján ilyet összevonni óriási butaság. A számlázó program teljesen megfelelően működik, de a működési környezetre nincs rálátásunk. A mi programjainkat használják több céges környezetben, vagyis egy számlázó program egy gépről és IP-ről több cég nevében is küldhet, kérdezhet adatokat...

[csaszko]

Én is értem a problémát, és kell is tenni ez ellen, hogy tudjon működni rendesen, de miért nem azokat büntetitek ezzel, ahonnan érkeznek a kérések? Csak be lehet határolni, hogy ki/kik azok...

[nbeeps2]

@NTCA-developer : ha jól emlékszem ez a gitHub pont azért lett létrehozva, hogy mielőtt bármi be lenne vezetve meg lehessen vitatni a fejlesztői társadalommal. Én nem emlékszem, hogy ez a téma fel lett volna dobva a mi megkérdezésünkkel, és ez durván kihathat az amúgy jól működő programok működésére is! Már várom a telefonrohamokat ismét....

[NTCA-developer]

Kérlek, olvassatok is, ne csak írjatok. A beküldések intervallumára NINCS rate limiting. Csak a feldolgozási eredmények lekérdezésére van a v2-ben. Ezért ezzel ne érveljetek.

[nbeeps2]

@NTCA-developer pontosan értjük, hogy a számlabeküldést nem érinti, csak a státusz lekérdezést, de akkor ezek szerint Te nem érted, amit mi írunk.

[csaszko]

Kérlek, olvassatok is, ne csak írjatok. A beküldések intervallumára NINCS rate limiting. Csak a feldolgozási eredmények lekérdezésére van a v2-ben. Ezért ezzel ne érveljetek.

Ezt írtam: Ebben az esetben aztán optimalizálhatsz kliens oldalon bármit.. nem is tudsz róla, hogy adott IP miért van tiltva és folyamatosan összeakadnak a lekérdezések.

[szako]

@NTCA-developer: számla beküldést írtam helyett státusz frissítés, elnézést. A kérdésem a státusz lekérdezésre vonatkozik.

[nbeeps2]

@NTCA-developer : IP cím esetén, ha helyi hálózatban használják a szoftvert mondjuk 10 munkaállomáson, és a lekérdezést a munkaállomások végzik (nem a szerveren futó job), akkor ez nektek 10 féle IP lesz a lekérdezésben vagy 1?

[nbeeps2]

@NTCA-developer: @EPluribusUnum által felvetett esetben mi a megoldás? Össze fog akadni neki a statuslekérdezés rendesen... Ez így nagyon nem jó, ezt nem gondoltátok át, ezért kellett volna minket megkérdezni, hogy milyen aggályok, problémák merülhetnek fel...

[nbeeps2]

@NTCA-developer "Ha jól számolom, akkor 1 másodpercen belüli időablakot nézve a másodiktól indul a késleltetés, tehát egy sec alatt egy forrás IP-ről 15+1 párhuzamos lekérdező szálat tudsz fenntartani. " Bocs ez nekem magas... Most egy sec alatt 1-et kérdezhetek vagy 15+1-et? Érti ezt valaki?

[rgform]

Ez úgy jött ki hogy 60 másodperc után tilt teljesen. 4 másodperceként emeli az időt 15 x 4 = 60, a plusz 1 az első még nem számolt... Vagyis elinditasz 16 ot azok sorban 0, 4 ,8, 12.... 60 késleltetést kapnak... a 17 már nem játszik...

[nbeeps2]

@rgform És meddig tart a tiltás vajon? ;)

[csaszko]

Szintén nem tudom mennyi számlát érinthet, de az előzőekkel együtt nézve, plusz egy dolog ami viszont az adatszolgáltatást befolyásolhatja. Módosító/sztornó számláknál meg kell várni amíg az eredeti feldolgozva van és done... Tehát nem csak azt kell most már esetleg megvárni, amíg feldogozott lesz, hanem azt is, hogy le tudd kérdezni... tehát folyamatosan valami logika alapján futtatod a lekérdezést amit Ti most (akármennyire is) de kontrolláltok. (Nem akarom folytatni az azonnali, nem azonnali értelmetlen vitát.. de ez okozhat érdekes helyzeteket.. )

[EnokhSys]

@NTCA-developer Az ég szerelmére, ezt így nehogy bevezessétek holnap, mert ebből megint közbotrány lesz!! Gondolkozzatok: csak a forrás IP-cím szűrés nem elég, hiszen fentebb is sokan jelezték, hogy több száz cég egy ip-címről kommunikál. Tegyétek hozzá a usert is, és ez így már rendben lesz.

[NTCA-developer]

@nbeeps2 Ez egy sürgős intézkedés. Nézd meg a válaszidőket. Nincs idő egyezkedni. Ez nem azt jelenti, hogy nem vagyunk partnerek veletek vagy hogy nem gondoltuk át ez mit okoz. Szerintünk semmit. De nem borulhatunk be csak azért, mert már annyi potyautasunk van, hogy nem bírunk velük, miközben egyre nő azoknak a kényelmi szolgáltatásoknak a használata, amiket pont az miatt építettük hogy használják.

Az a matek, hogy 15 másodpercenként beérkezik 5000+ token kérés és 3500+ státusz lekérdezés, miközben a legnagyobb csúcsban ebben a 15 másodpercben legfeljebb 1500 számla adatszolgáltatás érkezik. És a token meg a státusz lekérdezések ömlenek csúcsidőn kívül is. A tokenkéréseket korlátozni felesleges mivel lehetetlenül olcsó, nem nyerünk vele. A státusz lekérdezések se annyira drágák, de azon már lehet értelmes kapacitást nyerni.

@rgform 1 percig. Utána tiszta lappal indulsz ismét.

@csaszko Ez igaz, viszont /queryInvoiceCheck-el lehet kezelni. Meg úgy általában ez egy szűk réteg, hogy azonnali módosító számlát akarsz kiadni.

@EnokhSys Akkor holnap megállhat az éles, abból nem lesz? Mint mondtam ez L3-as megoldás, az L7 adatok számára nem hozzáférhetőek. Nincs lehetőség semmilyen üzleti adatra szűrni, legalább is ez a megoldás nem képes erre.

[csaszko]

Akkor az a javaslatom, hogy az ügyfelek felé a lejárató emailek küldözgetését (akármelyik kezetek is csinálja) szintén sürgős intézkedésként állítsátok le, ameddig "kiderül mit hoz az élet"!

[NTCA-developer]

@csaszko Sajnálom, de ennek a megbeszélése most nem segít a témán.

[nbeeps2]

@csaszko Nyissunk ennek külön topikot, mert amit írt az is óriási probléma és valótlan dolgokat állít a NAV, amit ha nem hagy abba, akkor mi már peren is gondolkozunk. Kimeríti a rossz hírnév keltés, márka rontás fogalmát.

[NTCA-developer]

@nbeeps2 Van már neki.

[szako]

@NTCA-developer: Ha minimális késleltetéssel (pl. 0,1s) működik jelenleg a rendszer kliens oldalon és egy process kérdezi le a számlák státuszát (a párhuzamosítást kikapcsoljuk és megvárja a process a választ), akkor az élesítés után 4 másodpercre fog változni kérések közötti időtartam, jól gondolom?

[csaszko]

Ezt, hogy érted? Változtattok valamit az éles rendszeren, - végig gondoltatok biztosan nagyon sok mindent-, de aminek még Ti sem láthatjátok a pontos működését (gyakorlati oldalát). Ezért gondoltam, hogy célszerű lenne ezt is meglépnetek. Ezért szerintem segít a témán, mert ha még levelezgetni is fognak a kollégáid, az mindenkinek csak még inkább megnövekedett terhet fog jelenteni.

[NTCA-developer]

@csaszko Sry, erre nem válaszoltam, gyorsan elmászott.

Ha 0,1 secenként küldesz lekérdezést, akkor a második kérés (nálad 0,2 secnél) már csak 4200,02 msnél érkezik meg a szerverhez. Mire eljutsz 0,17 sec-ig magadnál ezzel a logikával már a 17-ik kérésed timeoutra fog futni. Egészen addig, amíg 1 perc csendet nem hagytál a lekérdezésekben. Így érthető?

[EnokhSys]

@NTCA-developer Nem az 1 mp-es limittel van a gond, sőt, ez akár 2 mp is lehetne. Hanem a +4 sec-es halmozódó késleltetéssel és az 1 perc utáni kitiltás az aggályos, ezeket nagyon át kellene gondolni, mert nagyon ad-hoc jellegű, és - még akkor is, ha technikailag igazatok van -, az adózók törvényi kötelezettséget gátoljátok ezzel.

[NTCA-developer]

A kitiltás 1 perc után mindenképpen megtörténik, a külső hálózati eszköz elvágja a kapcsolatot. Szóval ebből a szempontból mindegy hogy a rate limiting maga terminál-e kapcsolatot, a külső eszköz mindenképpen már most is, kezdetektől fogva ezt megteszi. De egyébként ha nem is tenné, akkor a rate limiting semmit sem ér. Csak annyit csináltunk hogy a szinkron időhöz képest 4 másodperccel később ömlik ránk a forgalom. De akkor is ránk ömlik.

[balintdozsa]

@NTCA-developer A kitiltás meddig él?

[nbeeps2]

@balintdozsa 1 percig. Utána tiszta lappal indulsz ismét.

[nbeeps2]

Erre a korábban feltett kérdésemre még nagyon érdekelne a válasz:

@NTCA-developer : IP cím esetén, ha helyi hálózatban használják a szoftvert mondjuk 10 munkaállomáson, és a lekérdezést a munkaállomások végzik (nem a szerveren futó job), akkor ez nektek 10 féle IP lesz a lekérdezésben vagy 1?

[Rossi73]

Semmiféle problémát nem látunk ezen a téren, hogy nem azonnal, hanem X perc múlva kapjátok csak meg a feldolgozási eredményt.

Kedves @NTCA-developer! Ha péntek délután, munkaidő végén eddig megtörténhetett az x db beküldött számla státuszának lekérdezése, ami után a dolgozó megnyugodva hazament, de ezt követően lehet, hogy hosszabb időt kell túlóráznia, mert egy másik cég az irodaházban épp akkor küldi be és kérdezi le a tömeges számláit, akkor bizony ő joggal érezheti azt, hogy ez neki problémát okoz. Azt pedig ne felejtsük el, hogy az NGM rendelet ezt mondja:

"(3) A számlázó programmal történő adatszolgáltatás akkor minősül teljesítettnek, ha az (1) bekezdés szerint történt a benyújtása, és a sikeres feldolgozást az állami adó- és vámhatóság rendszere visszaigazolta."

Tehát, nem elég a beküldés, meg kell győződni a sikerességéről is. Ha ez most akadályba ütközik, akkor neki (jóhiszeműen) meg kellene várnia. Mert ha nem várja meg (mert nem tudja), csak hétfőn kérdezi le, és hétfő már másik hónap, akkor az előző hónapban nincs lekérdezve, a NAV pedig majd küldi megint a dörgedelmes levelet, hogy nem kérdezte le, hibás a számlázó program, javíttassa a fejlesztővel!

Tegnap csak azzal borzolta a NAV a kedélyeket, hogy a NAV saját hibáját kente rá a fejlesztőkre, most pedig bevezeti ezt a szabályt, minden előzetes értesítés nélkül. Inkább vegyétek fel a kapcsolatot azzal a 10-20 (nem tudom, mennyi) fejlesztő céggel, és utasítsátok őket a megfelelő használatra! Vagy, ha megvan az a 200 IP cím, amiről jönnek a "szabálytalan" működések, akkor korlátozzátok be azt, ne pedig a többi több 100 ezer felhasználót...

Előre is köszönjük!

[EnokhSys]

@NTCA-developer Értsd meg a lényeget: nem tilthatjátok ki az ip-címet a törvényi kötelezettség miatt. Még 1 percre sem. Értem én, hogy informatikailag ez a megoldás a kézenfekvő, de a törvényi előírás a magasabb.

[Rossi73]

Utóirat: arról nem beszélve, hogy ez "csak" egy hírben jelent meg a NAV online számla oldalán. Nem kellett volna erről más csatornán értesítést küldeni? Vagy a NAV elvárása, hogy ezek szerint napi szinten olvasgassa mindenki a Hírek oldalt is? (Igen, "a fejlesztők sose mennek szabadságra, tudom, tehát akár idejükbe bele is fér"...)

[nbeeps2]

@EnokhSys : erre az lesz a válasz, hogy a számla beküldésben nem vagy korlátozva (mert csak a státusz lekérdezést érinti), a lekérdezés meg ráér 1 perc után is.

[EnokhSys]

@NTCA-developer igaza van Rossi73-nak, egy ip-filter listát kellene beállítani a kérés-bombázós ip-címekkel, és csak azokat bekorlátozni, ill felvenni velük a kapcsolatot.

[nbeeps2]

@EnokhSys erre ez volt a válasz: "Ez egy sürgős intézkedés. Nézd meg a válaszidőket. Nincs idő egyezkedni. "

[EnokhSys]

@EnokhSys : erre az lesz a válasz, hogy a számla beküldésben nem vagy korlátozva (mert csak a státusz lekérdezést érinti), a lekérdezés meg ráér 1 perc után is.

@nbeeps2 NEM, én nem erről írtam, hiszen a törvény nem csak a beküldést írja elő, hanem a lekérdezést a számla feldolgozás sikerességéről.

[EnokhSys]

@EnokhSys erre ez volt a válasz: "Ez egy sürgős intézkedés. Nézd meg a válaszidőket. Nincs idő egyezkedni. "

Nanee! Egy ip-filter listát összeállítani akár 1000 ip-címre egy ip-log file alapján, nehogy már ne lehessen 1 óra alatt megcsinálni.

[nbeeps2]

@EnokhSys ezt én értem, hogy csak akkor teljes a beküldés, ha ellenőrizted és sikeres, de @NTCA-developer szerint ez hogy 1 perccel később tudod csak lekérdezni az adatszolgáltatás sikerességét, az nem gátol téged, csak késleltet, hogy ennek eleget tegyél. De persze én sem értek egyet ezzel az egésszel (késleltetés bevezetése), amit fent már több ízben megfogalmaztam.