REST-el kapcsolatos kérdésem lenne. Ha csak a szolgáltatáshoz tartozó Swagger UI url-t ismerem (http://.../swagger-ui.html/), akkor valójában a tényleges endpointot nem tudom? Eleve annak https-nek kellene lennie. Nem titok, a Yettel sms futárról van szó, valamiért a SOAP interfészt nem tudtam rávenni az üzenetek összefűzésére, ezért próbáltam volna a REST-et. Az ügyféltől meg fogom kapni valamikor a választ, de volt ma kis időm foglalkozni vele, és bosszant, hogy elakadtam.

Picard: "What we leave behind is not as important as how we've lived. After all, Number One, we're only mortal." Riker: "Speak for yourself, sir. I plan to live forever."

OpenAPI specifikaciojaban van egy server object ott lenne a remote API base urija.
Utána pedig a paths nevű objectet kell nézni, abban lesznek a routek.
Tehát egy request címét ebből a kettőből tudod össze rakni, fűzni.

[ Szerkesztve ]

Na olyanom pont nincs.

Picard: "What we leave behind is not as important as how we've lived. After all, Number One, we're only mortal." Riker: "Speak for yourself, sir. I plan to live forever."

Publikus ez a dokumentáció?
Akkor tippre valahol ott lesz mellette. Amúgy mi értelme lenne ennek a swagger dokisnak

REST Api leírás van csak, ebben szerepel a swagger ui url-je.

Picard: "What we leave behind is not as important as how we've lived. After all, Number One, we're only mortal." Riker: "Speak for yourself, sir. I plan to live forever."

Tedd ide az URL-t.

while (!sleep) sheep++;

Nem publikus, ahogy nézem. A WS-é megtalálható a neten kereséssel, a REST nem.
Így néz ki böngészőben:
Edge:

Firefox:

Picard: "What we leave behind is not as important as how we've lived. After all, Number One, we're only mortal." Riker: "Speak for yourself, sir. I plan to live forever."

Na csak nem válaszolt az ügyfél, de ha a megadott swagger ui url-ből kitöröltem egy 99-et, akkor máris a jó felület jelent meg. És innen már persze minden kiderült és működik is. Érdekes egyébként, hogy a webservice módon nem tud több sms-t összefűzni a szolgáltatás, a REST igen. A webservice-nek van egy MoreMessToSend paramétere, ahol jelezni lehetne, hogy van még üzenet, de itt pl. nincs message id, amivel jelölni lehetne az összefűzendő részek összetartozását.

Picard: "What we leave behind is not as important as how we've lived. After all, Number One, we're only mortal." Riker: "Speak for yourself, sir. I plan to live forever."

Ez most egy kicsit furcsa kérdés lesz, de azért csak had kérjek róla véleményt.

UDP-ről olvastam az rfc768 és 1122-t. Ugyan explicite nincsen kijelentve, hogy tilos egymást követő csomagoknak összeragadniuk, de az udp csomagokban ott van egy hosszúság, és szerintem elvárható, hogy az is tiszteleben legyen tartva. Például egymás után 2 csomag ugyan arról a forrásról érkezik be ugyan arra a cél címre, és az egyik 4 byte hosszú, a másik 8. Ha a fogadó állomás egybe ragasztja őket 12 byte-ra, az szerintem protokol sértés. De ebben a kérdésben a ti véleményeteket is szeretném kikérni. Ha valaki úgy gondolja, nem protokol sértés, miért gondolja úgy?

Linux Ubuntu 22 alatt ellenőriztem, az udp csomagok abban a környezetben nem ragadnak össze.

កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។

Mit ertesz egybe ragasztas alatt? Egy kuldo ket kulon UDP csomagot kuld, aminek ket kulonallo header-je van? Es ezt amikor megkapja a vevo, akkor ugy nez ki, mintha egy csomag jott volna be, egy tok uj headerrel, es a kuldott data-k konkatenalasaval? Milyen receiver-rol beszelunk es miert zavar, hogy igy kapja meg? Feltetelezem azert, mert te tole kapod meg az adatot. Biztos, hogy nem maga a kuldo rakta mar ossze egy csomagba elkuldes elott?

I am having fun staying poor.

A küldő még biztosan két külön csomagban adja fel. Nem tcp hanem udp.

És igen, egybe ragasztás alatt azt értem, hogy a helyi oprendszer socket kezelése két egymás után beérkező csomagot egybe ragaszt. A helyi user space app azt látja, hogy a küldő címéről X hosszú csomag érkezett, és nem egy 4 hosszú csomagot kap, és utána egy 8 hosszú csomagot, hanem egy darab 12 hosszú csomagot kap.

És hogy miért zavarna? Mondjuk mert az udp-ről én úgy látom, hogy kényelmes dolog teljesítménnyel döngetni ami a csövön kifér, és akkor se kelljen csomag méretek megállapítására extra cpu-t használnom a túloldalon.

កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។

Wireshark, vagy hasonlo tool is azt mondja, hogy biztosan 2 kulon UDP packet received, vagy a kuldo oldalon sent? En is nagyon meglepodnek, ha 2 kulon kuldott csomag egyben erkzene meg. Milyen lib-eket hasznalsz a kuldesre es a fogadasra? Az o dokumentaciojuk mit mond arrol, hogy hogyan kezel buffereket?

I am having fun staying poor.

Ma reggel arra ébredtem, hogy erre anno rácsodálkoztam win xp vagy win 7 időben. Már nem emlékszem biztosan, melyik volt, és hogy win crt vagy dotnet volt-e. A kettő közül valamelyik ragasztott. És most abba futottam bele, hogy ha ragasztás esetével összetalálkozom a jövőben, nagyon fog leverni a víz. Hogy valami framework ragaszt, az nem a legnagyobb probléma. Linux-on a Berkeley socket nem ragaszt - teszteltem. Az a legfontosabb. Win 10-et mindjárt megnézem, 11-em nekem még nincsen. Ami megnyugtató lett volna, ha a standard kerek-perec kijelenti, hogy tilos kernel space és user space közé bármilyen csomag manipulációs réteget iktatni be, ami a datagram-okat darabolni vagy ragasztani tudja, mert amelyik os olyat csinál, annak a pöcse le lesz vágva. De sajnos nem találtam olyan explicit kijelentést.

កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។

Az UDP egy connectionless protokoll.
Vagyis minden csomag teljesen különálló. Nem garantált a csomagok sorrendje, nem tudod megmondani, hogy egyáltalán megkapta-e a címzett a csomagokat, és azt sem tudod megmondani, hogy melyik két csomag "tartozik össze".

Szóval nem igazán tudom elképzelni, hogyan fogja ezeket összeragasztani bármilyen oprendszer.

Szóval ahogy írod, kényelmes dolog teljes sebességgel döngetni, és fosni a byteokat a hálózatra, abban az esetben, ha nem érdekel, hogy a címzett megkapta-e az összes csomagot, és az sem érdekel, hogy milyen sorrendben.

[ Szerkesztve ]

Sziasztok,

Számlázó programmal kapcsolatban lenne kérdésem , ha valaki foglalkozott vele.
NAV online számlabeküldést hogyan tudom tesztelni?
Különböző cégekhez kellenének ilyen teszt xml kulcsok, stb..
Nézem az "oktató videót", hogy ügyfélkapuval kellene belépni?
Most saját ügyfélkapuval gondolja ezt tényleg?
Meg ez van a leírásban:

I.4. kérdés: Ha a számlázó rendszer előre készül – azaz a felhasználó még nem ismert –, akkor van-e mód a tesztkörnyezet használatára, például valamilyen fiktív cégként?

A tesztrendszerbe csak élő gazdasági társaság, illetve egyéni vállalkozó törvényes képviselője vagy állandó meghatalmazottja jelentkezhet be. Mindezekből adódóan fiktív cég bejelentkezésére nincs lehetőség. Ugyanakkor a tesztrendszerbe küldött adatok – a tesztrendszer jellege miatt – nem számítanak adatszolgáltatásnak, az ilyen adatokról senki sem feltételezi, hogy valósak.

Akkor nem is lehet elvileg nekem ezt kipróbálni?
Kellene pedig pár "próba cég" akikkel megnézem, hogy ez egyáltalán működik-e...

Köszönöm,

Próba cég nincs, mert a tesztrendszerbe is csak valós adóalanyok regisztrálhatnak. Ha nincs konkrét ügyfeled, akkor a saját nevedben kell tesztelned.

Picard: "What we leave behind is not as important as how we've lived. After all, Number One, we're only mortal." Riker: "Speak for yourself, sir. I plan to live forever."

Az eredeti adatbázishoz hozzá lehet férni?
Nem lehet azon pl. triggerekkel lekezrlni, hogy az új adatbázisba "dobja át" a változást?

Bar ehhez nagyon össze kell kötni a 2 adatbázist.
De ha an rá lehetőség, szerintem ez a legegyszerűbb.

Szuper.
Saját nevemhez adjak hozzá valamilyen cégeket, hogy tudjam ellenőrizni, hogy működik-e?
Pont azt írják azt nem lehet.
Nagyon jól kitalálták.

Nem, annak a cégnek, akinek fejlesztesz, kérd el az ügyfélkapus hozzáférését és azzal azonosítsd magad a teszt rendszerben, máshogy nem fog menni. Ha nincs ilyen bizalmi viszony közöttetek, akkor ez egy döglött ló.

Hát akkor is csak egy céghez lesz jó esetben azonosító kulcsom, de több céggel is ki kellene azért próbálni.
Mert ugye azt majd akármilyen cég meg vásárolhatja.
Tényleg szuper, hogy erre a navnal nem gondoltak, hogy mégis jó lenne.
Vagy valami teszt kulcsok legalább.

Meghatalmazottnak kell lenni, ennyi elég.

Nem értelek, hogyan csinálsz akkor technikai felhasználót a teszt rendszerben?

Szerk: ja értem, a cég csinálja meg neki, az is jó, nyilván valamiféle cégként a saját belépésével vagy alkalmazottként van valami hozzáférés. Nyilván én is a saját cégünk adataival léptem be még anno a fejlesztés kezdetekor, hogy megnézzem az eredményt, meg hogy technikai felhasználót hol kell csinálni, mert a felhasználóknak fingjuk nem volt induláskor, hogy mit kell csinálni.

Szerk2: a technikai érvénytelenítés jóváhagyásához viszont sanszos, hogy meg fogják adni az adatokat, mert képtelenek bizonyos helyeken erre rákattintani, ez tapasztalat

[ Szerkesztve ]

Azure-ban van most fent valaki több szerverrel?

Van a privát hálózati csoport. Azon belül gondolom local domain címeket lehet beállítani, és az valami szoftveres emulációval fut a virtuális szerverek között. Ami érdekelne róla, mekkora a ping idő eltérő fault domain-en lévő virtuális szerverek között a beállított privát hálózaton. Ha valaki tesztelte már, tapasztalatnak örülnék.

កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។

Szervusztok!

Elnézést, ha nem jó helyen keresgélek, de programozási segítséget keresek és NAGYON nem vagyok gyakorlott fórumozó. Segítene valaki, hogy hol keressek olyan partnert, aki segíteni tudna vagy meg tudná oldani az alábbi problémám?:

Az offline számlázó programom készlet és áradatait szeretném folyamatosan frissíteni a webshopon található termékekkel automatizáltan.

A számlázó egy .csv fájlba bele tudja rakni az adatokat és fel is tölti ezt, ha kell a saját ftp-re, innen kéne valahogy megoldani, hogy a csv-ben lévő ár és termék készlet adatok a cikkszám alapján azonosítva bekerüljenek a webshop adatbázisba időről időre. Persze ez talán úgy lenne még jobb ha ez a .csv mindig bekerülne az adatbázisban egy saját táblába és onnan kerülne át az adat a megfelelő másik tábla megfelelő oszlopaiba. Remélem érthető voltam és köszönöm

Szóval,

(1) Van egy .csv valahol háttértárolón - az már megoldott.

(2) Abból szeretnél adatokat küldeni egy webshop api felületére - ez hiányzik.

(3) A webshop gondoskodik a többiről - az adott.

Így értetted?

កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។

Nem irtad milyen adatbazisrol van szo, de a legtobb tud olyat, hogy csv-t olvas fel egy tablaba. Innentol mar csak hozza kell irni az uj rekordokat/updatelni a regieket a beolvasott tablaval.
Ja es persze automatizalni az egeszet. Erre lehet irni egy cron jobot, vagy hasznalni az adatbazis job servicet.

(2) Lehet, hogy így gondolom, de nem tudom biztosan mert gondolom erre is több megoldás létezhet. Marky18 gondolatát képzeltem el én is csak nem tudtam így megfogalmazni.

phpmyadminon van egy mysql adatbázis. Ide gondolnám én feltenni a csv tartalmát egy táblába. Aztán gondolom ehhez kellene 1 parancs ami az X táblából a A és B oszlopot frissítené Y tábla C és D oszlopával. Persze csak akkor ha a 2 táblában a cikkszám oszlop =. Mert nem ugyanazok a termékek szerepelnek a számlázóban mint a webshopban. Lehetnek eltérések mert a számlázóban több tétel szerepel.
Esetleg annyi, ha számít, hogy valahogy figyelni az is, hogy az előző állapothoz képest mi változott és csak azt futtatni. Nyilván több ezer tételnél már számíthat, hogy mindig lefut az egész vagy csak a változás frissül.
És igen a végén én is egy Cron feladattal szerettem volna frissíteni. kb. ennyi

[ Szerkesztve ]

Nekem Marky18 írása ugyan úgy hiányosnak tűnik. Ő egy csv és adatbázis kapcsolatára tett megjegyzést, és egy szót sem említett a webshop-ról. Továbbra sem tiszta, mire lenne igazából szükséged.

Második olvasatra valami ilyesminek tűnik eddig:

-A webshop-ban folyamatos értékesítés zajlik, azok az adatok a webshop-ból letölthetőek, és te le szeretnéd tölteni.
-A webshop-ból letöltött adatokat importálni szeretnéd a számlázódba valamilyen formában.
-A számlázódban módosítanál értékeket, mint például az eladás függvényében ármódosításokat végeznél termékeken.
-A számlázódban elvégzett módosításokat exportálnád azzal a céllal, hogy azt a webshop-ba visszaküldd.
-Fel kellene tölteni számlázóból exportált adatokat a webshop-ba.

Mielőtt további kommunikációs hiba történik, rákérdeznék, hogy a fenti elgondolás az-e, amire te gondoltál?

កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។

GCC fordítónál létezhet valami olyan optimalizálás / kapcsoló, amivel megengedem a fordítónak, hogy a struc-okon belüli változó sorrendet is átalakítsa memória felhasználást hatékonyabbá tenni? Mondjuk char-ok között vannak int-ek, meg long long int-ek, és abszolút nem memória-hatékony a sorrend - logika szerint van rendezve denormalizáltan (több külön egység is közös struc-ban van).

កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។

A szabvany ezt nem engedi meg.

while (!sleep) sheep++;

-fipa-struct-reorg
Volt, a GCC 4.8.x verzióig. De aztán eltávolították, mert a C szabvány nem engedi meg és többféle galibát tud okozni.

I am having fun staying poor.

A webshopból --> számlázóba irány már megoldott.
A gond az, hogy webshoptól függetlenül is történik értékesítés, ezt a számlázó és készletnyilvántartó kezeli, de a számlázó csak annyit tud csinálni, hogy beállítás után időről időre készít egy csv-t amiben benne van a pillanatnyi készlet és, ha kell, az ár.
Ez kéne szinkronizálódjon a webshoppal.
Tehát az első két bekezdés megoldott, a harmadik mondjuk ok és a 4.-et megcsinálja a számlázó (ez a csv), az 5. bekezdés ami hiányzik.

A webshop egy db-bol dolgozik, ha frissiti a tablakat, akkor frissiti a webshopot.
Felreertettem valamit?

[ Szerkesztve ]

Amin én, @Marky18, és @axioma még egy kicsit információt hiányolunk, az az a részlet, hogy mit jelent a te esetedben "a webshop"? A helyi szerveren fut valami opencart vagy akármi framework, ami a helyi DB-ből szedi az adatokat? Vagy valami külső szolgáltatást vettél igénybe mint shoprenter, unas, vagy bármi egyéb másik fél által nyújtott szolgáltatás?

Ha helyi gépen dolgozik a webáruházad, akkor helyi db-ben kotorászva is fel lehet tölteni adatokat - tranzakcióval tudsz érkeztetni. Ha külső szolgáltatás, akkor kérdéses, hogy melyik? A legtöbbjénél van webapi támogatás, de nem kompatibilisek egymással, és szó nincsen arról, hogy az ilyesmi szabványosítva lenne. Per webáruháza válogatja, mit hogyan lehet.

Más

@emvy, @Drizzt GCC tájékoztatás köszönöm.

[ Szerkesztve ]

កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។

Lazán kapcsolódó eset:
Én a NAV online számlázó rendszerében azt nem értettem, hogy miért jó, ha fizetési határidőnek meg lehet adni múltbeli időpontot is. (Megtörtént eset: számla kiállításának ideje 2023.03.02 (mondjuk), fizetési határidő: 2022.04.01.) Jelentettem a hibát, visszaírtak, hogy ez nem bug, hanem feature (lényegében). Persze az is lehet, hogy a NAV-nál feltalálták az időgépet, és ehhez igazították a rendszerüket, mert onnantól az idő már nem fix struktúra, és simán előfordulhat, hogy előbb megtörténik a fizetés, aztán (hónapokkal később) a számla kiállítása, majd megállapodnak a felek, hogy milyen gazdasági ügyletbe is fognak (fogtak?) egymással kezdeni...

Nem lehet körökre osztott módba váltani, mert a karakter halott.

Ipv6 port scan - lehetséges a gyakorlatban?

Ipv4-nél még csak-csak okés, hogy amit a tűzfal le nem zár, azt nekiállni üzenetekkel nyaggatni, hátha visszaérkezik róla bármi, mert egyetlen fix ip cím, és "csak" a 64k (16 bit) port területet kell végig kotorni. Ipv6 esetén maga az ip blokk legalább 32 bitnyi (és nem ritkán 64), plusz még a port 16 bitje. Én azt sejtem lehetetlen, de ha benéztem valamit, egy kupáncsapást had kérjek.

Létezik bármi protokol, ami végigkotrás nélkül ki tudja deríteni egy ipv6/32 tartományban a létező ip címeket?

Amit a témában eddig találtam "port scan" és társai, fake minden. Domain címek AAAA rekordját lekérdezni meg a helyi router service portot kiírni - ezek nem azok.

[ Szerkesztve ]

កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។

Kezdőként, hobbi színten desktop (fájlok olvasása + írása, szerkesztése, + kis adatbázis) alkalmazások fejlesztéséhez, melyik nyelvet érdemes választani? Python vagy C#?

JBL Synthesis -> Egy hangrendszer mind fölött, egy hang kegyetlen, egy a nyomorba dönt ( árával biztos), bilincs az Egyetlen

Én a Qt-t ajánlanám, de az nincs a listában.

Nem lehet körökre osztott módba váltani, mert a karakter halott.

A file szerkesztés nem tudom, mihez kellhet, de ha byte szinten bináris állománnyal dolgoznál, a C# jobb. Ami a többit illeti, PHP-val szereznél könnyebben és gyorsabban sikerélményt. Van a PHP-nak command line futtatója, nem csak webezésre lehet azt használni.

កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។