-
Fototrend
Új hozzászólás Aktív témák
-
rgeorge
addikt
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."
-
rgeorge
addikt
-
rgeorge
addikt
válasz rgeorge #18811 üzenetére
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."
-
coco2
őstag
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.
កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។
-
Drizzt
nagyúr
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.
-
coco2
őstag
válasz Drizzt #18814 üzenetére
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.
កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។
-
Drizzt
nagyúr
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.
-
coco2
őstag
válasz Drizzt #18816 üzenetére
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.
កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។
-
cucka
addikt
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 ]
-
lm83
őstag
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,
-
rgeorge
addikt
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."
-
lm83
őstag
-
dabadab
titán
Azt nem értem, hogy miért kellene több cég: a tesztrendszeren mindegyik pont ugyanúgy néz ki (alapból tök üresek).
Egyébként meg neked nem kell semmi extra, az ismerős céget megkéred, hogy generáljanak neked egy user+pass párost a tesztrendszeren (fontos, hogy ott, mert az éles és a tesztrend teljesen külön rendszerek) és akkor azzal tudsz tesztelni, nem kell az ügyfélkapus usereddel semmit sem csinálni.[ Szerkesztve ]
DRM is theft
-
baracsi
tag
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 ]
-
coco2
őstag
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.
កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។
-
kiaszabadba
csendes újonc
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
-
coco2
őstag
válasz kiaszabadba #18830 üzenetére
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?
កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។
-
Marky18
aktív tag
válasz kiaszabadba #18830 üzenetére
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. -
kiaszabadba
csendes újonc
válasz Marky18 #18832 üzenetére
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 ]
-
coco2
őstag
válasz kiaszabadba #18833 üzenetére
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?
កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។
-
coco2
őstag
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).
កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។
-
kiaszabadba
csendes újonc
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. -
coco2
őstag
válasz kiaszabadba #18840 üzenetére
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 ]
កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។
-
VikMorroHun
senior tag
válasz baracsi #18828 üzenetére
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.
-
coco2
őstag
válasz VikMorroHun #18843 üzenetére
Már jó ideje úgy zajlik a nav-nál a játék. Ha mást hittél, hát naív voltál.
[ Szerkesztve ]
កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។
-
coco2
őstag
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 ]
កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។
-
paler
aktív tag
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
-
dabadab
titán
válasz VikMorroHun #18848 üzenetére
De, ott van PyQt: [link] (Qt Pythonhoz - ha GUI kell, akkor szerintem ez a legjobb választás)
[ Szerkesztve ]
DRM is theft
-
coco2
őstag
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.
កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។
Új hozzászólás Aktív témák
● olvasd el a téma összefoglalót!