- Xiaomi AX3600 WiFi 6 AIoT Router
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Kodi és kiegészítői magyar nyelvű online tartalmakhoz (Linux, Windows)
- Milyen switch-et vegyek?
- Linux kezdőknek
- Hálózati / IP kamera
- Sweet.tv - internetes TV
- A Microsoft feltalálta az olcsó AI-t
- Musk szerint már jövőre itt vannak a Tesla Optimus humanoid robotok
- Otthoni hálózat és internet megosztás
-
IT café
Új hozzászólás Aktív témák
-
McSzaby
őstag
válasz jattila48 #8927 üzenetére
Szia,
kb. 150-200 kliensről van szó.Titkosításra nem lesz szükség szerintem, a hálózati csomópontok, illetve egyebek elég jól védettek a hálózaton. Ha valaki már odáig eljut, hogy itt hálózati forgalmat tudjon nézni, akkor már rég mindegy a történet.
Tudom, hogy google a barátom, de nem tudnál/tudnátok esetleg adni valamilyen leírást, "howto"-t, ahol az ilyen témát taglalják és vehetem referenciának?
#ThankYouSirAlex #ThankYouLouis
-
Karma
félisten
válasz jattila48 #8935 üzenetére
TCP kapcsolatot megírni valóban gyerekjáték, kb. bármelyik nyelven, de messze eltörpül a tényleges feladat mellett. Tényleg jelentéktelen. Ha házi megoldás kell, akkor se ez az az idióma amivel el lehet indulni értelmesen egy ekkora kliensszám és a fejekben élő stabilitási kritériumok mellett.
Az eredeti kérdés politikai vonzatára visszatérve: egy házi barkács megoldásnak semmilyen supportja nincs, csak addig az ideig-óráig, amíg foglalkozik vele a barkácsoló fejlesztő. Rá egy hónappal már teljesen esélytelen. Nem tudom milyen vezetés az, aki ezzel még nem égette meg magát, de sajnos valóban előfordul ez az ultrarövidtávú szemlélet...
[ Szerkesztve ]
“All nothings are not equal.”
-
McSzaby
őstag
válasz jattila48 #8935 üzenetére
(#8937) jattila48:
A többi része már megoldott fejben.Igazából nekem 2-2,5 hónapom van erre, szóval ja...
Rengeteg a nyitott kérdés, szóval egyelőre ez az egész kérdés, amit feltettem csak elméleti síkon mozog. Lehet PERL-ben írom meg, mert abban jóval több tapasztalatom van. Ott egy démon leprogramozása, socket nyitás "szinte" már csuklóból megy. De alapvetően egy TCP kommunikációt én sem találok nehéz feladatnak. Persze, itt azért a bonyolultsága nagy kérdés.
A probléma az itt, hogy megkötik a kezem és emellett szinte semmi segítséget nem kapok. Ezért kell egy hülye biztos, moduláris, céges platform független fost alkotnom és igen, elnézést a kifejezésért, de ebből csak fos lesz, mert én sysadmin vagyok, nem programozó.
Rengeteg a piacon fellelhető toolt kellett már a cégnél lefejlesztenem és nem értem miért nem lehet ELK Stack-t, Nagiost, Puppet-t, Chef-t használni.
Szóval, nagyon szépen köszönöm a segítségeket, véleményeket, ezeket mind meg fogom fontolni és eszerint döntök!
Nagyon köszönöm!
[ Szerkesztve ]
#ThankYouSirAlex #ThankYouLouis
-
dqdb
nagyúr
válasz jattila48 #13011 üzenetére
A Windows ReplaceFile API függvényével kapcsolatban érdekelne, hogy az mennyiben tekinthető atomi műveletnek.
Ha átadsz backup fájlnevet, akkor a hívó szempontjából közel atominak tekinthető. A közel szó arra vonatkozik, hogy az eredeti fájl tartalma megmarad, csak az attribútumai nem (részletek itt).A kérdésem az, hogy a Windows preemptív ütemezője átadhatja-e a vezérlést másik thread-nek/processznek a ReplaceFile végrehajtása közben.
Természetesen. És mivel jellemzően egyetlen szálnál több létezik manapság egy processzorban, így még a preemptív végrehajtásfelfüggesztés sem kell ahhoz, hogy párhuzamosan más is fusson.Mert az, hogy a ReplaceFile teljesen vagy egyáltalán nem hajtódik végre, rendben van, de előfordulhat-e, hogy a ReplaceFile véhrehajtása közben egy másik thread megpróbálja megnyitni a helyettesítendő file-t?
Előfordulhat.Ekkor ugyanis lehet, hogy a másik thread nem fogja tudni megnyitni a file-t.
Ha olyan sharing flagekkel nyitja meg, amit a ReplaceFile nem enged, akkor nem fog sikerülni, ha olyannal, hogy engedi, akkor igen.Ha a ReplaceFile olyan értelemben lenne atomi, hogy az ütemező közben nem adhatná át a vezérlést másik thread-nek, akkor ez a probléma nem léphetne fel.
Vagyis egy ReplaceFile hívás blokkolná a teljes operációs rendszert arra az időre, ami nyilvánvalóan nagyon nem jó.TxF kell neked, és ott a MoveFileTransacted hívást, aminél minden fél számára atomi művelet a mozgatás. Vagy gondold át a választott megoldást, mert a legtöbb esetben más működést választva eliminálhatóak azok az esetek, amelyekre most választ keresel.
[ Szerkesztve ]
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
válasz jattila48 #13015 üzenetére
ha az a problémád, hogy lesz olyan pillanat, amikor a fájl nem létezik, ezért nem nyitható meg, akkor ne rename-mel meg mozgatással dolgozz, hanem csonkold.
linuxon ez úgy működne, hogy kimásolod a tartalmát, majd belemásolsz egy fájl vége karaktert az elejébe, ettől levágja az egészet. windowst nem ismerem. truncate-nek szokták hívni angolul.Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
dqdb
nagyúr
válasz jattila48 #13015 üzenetére
előfurdulhat-e a ReplaceFile végrehajtása közben, hogy a helyettesítendő file név pillanatnyilag nem létezik (mert temporálisra lett átnevezve), miközben egy másik thread próbálja megnyitni
Igen, előfordulhat. És az is, hogy a fő szálon azért száll el a ReplaceFile hívás, mert egy másik szál FILE_SHARE_DELETE flag nélkül nyitotta meg a fájlt és még nyitva tartja.De mindkét eset könnyen érzékelhető és kezelhető a fő és/vagy a többi szál kódjának módosításával.
Ha IPC-re használsz ilyen módon fájlokat, akkor továbbra is azt tartom, hogy a megoldást kellene átdolgozni olyanra, ami nem igényel atomi műveleteket. Vagy ha nem szükséges az üzenetek perzisztens tárolása arra az esetre, ha a többi szál nem futna, akkor a fájlok használatától is teljesen el lehet tekinteni.
bambano: windowst nem ismerem. truncate-nek szokták hívni angolul.
Vagy TRUNCATE_EXISTING paraméterrel kell meghívni a CreateFile-t (ez csak akkor működik, ha már létezik a fájl), vagy CREATE_ALWAYS paraméterrel, és ez vagy létrehozza az új fájlt, vagy truncate-eli a már létező fájlt.[ Szerkesztve ]
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
válasz jattila48 #13019 üzenetére
Erre a célra szerencsésebb lenne a FindFirstChangeNotification használata FILE_NOTIFY_CHANGE_LAST_WRITE filterrel, és a többi folyamat érzékelné a fájl változását a változást követően, nem kellene aktívan monitorozni a fájl tartalmát, töredékére esne az elérési ütközések száma. Ezután a többi folyamat FILE_SHARE_READ sharing flaggel nyitná meg a fájlt (azaz amíg nyitva tartja, addig a fő folyamat nem tudná módosítani azt. nem lesz dirty read), ha nem sikerül, akkor pár tizedmásodperccel később újra próbálkozik. Ha a fő folyamatnál nem sikerül a ReplaceFile hívás, akkor az is pár tizedmásodperccel később újra próbálkozik.
Szerintem érdemes lenne a mostani konfigurációs fájlnak nevezett dolgot kettéválasztása szigorúan konfigurációs fájlra, ami nem módosulna és állapotfájlra, amit a fő folyamat módosítana. Vagy bármi más megoldás (pipe, socket, zeromq, MSMQ, stb.), ahol a fő folyamat értesítené a többi folyamatot, hogy itt van új állapotadat, tessék azt használni.
[ Szerkesztve ]
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
válasz jattila48 #13018 üzenetére
de akkor rossz helyen keresgélsz, mert a rename lehet atomi művelet, de a rename + create biztosan nem lesz egyetlen oprendszeren sem az.
ha neked az a feladatod, hogy létrehoztad egy temporális fájlban az új tartalmat, amit a helyettesítendő fájl helyére kell tenni, azt linuxon lehet atomi műveletként csinálni, a temporális fájlt átnevezed az eredetire. tehát nem azzal kell foglalkozni, hogy eltakarítsd a régit, hanem azzal, hogy az újat oda tedd a helyére. a régit majd eltakarítja a kernel.
rossz megoldás pszeudokódban:
move file file.backup
move file.new file vagy rename file.new filejó megoldás pszeudokódban:
move file.new fileEgy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
-
válasz jattila48 #13025 üzenetére
linuxon ott az inode. mivel van inode-od, egy fájlt akkor is el tudsz olvasni, ha azután, hogy megnyitottad, letörölték. a linux azt csinálja, hogy számolja a referenciákat az inode-ra, és amikor az lemegy nullára, törli a fájl tartalmát. a könyvtárbejegyzés és a megnyitott file handlere is referencia.
az átnevezés meg annyi, hogy az egyik könyvtárbejegyzésből kinézi, hogy melyik inode-ra mutat, és beleírja a másikba. egyszerűen felülírja a másikban az inode azonosítót. ezért atomi, mert vagy az előző tartalmat tudja egy másik processz beolvasni, vagy az újat, köztes állapot nincs.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
martonx
veterán
válasz jattila48 #13025 üzenetére
Van értelme ezen ennyit vergődni? Tényleg van olyan file-od, ami setting és folyamatosan változni is fognak a beállítások? És ha tényleg van ilyen, akkor nem egyszerűbb adatbázisban tartani?
Illetve a .Net világában a settings file-ok változásának lekövetését file watcherekkel szokták megoldani, azaz amikor a file watcher bejelez, hogy megváltozott a file, akkor ismét kiolvasod, amit ki akarsz olvasni, és kész.
Én kérek elnézést!
-
martonx
veterán
válasz jattila48 #13030 üzenetére
Válaszokat kaptál, a problémádat meg tudod oldani. A windows, linux gondolom nem kell részletezni, de nem ugyanazok, ergo eltérhetnek egymástól működésben. Azaz ez már csak vergődés, flamelés, trollkodás amit még itt csinálsz információ gyűjtés címszó alatt.
Én kérek elnézést!
-
opr
veterán
-
opr
veterán
válasz jattila48 #16449 üzenetére
Olvasd el azt is, ami elotte van...
"Ha valamilyen geppel probalsz mondjuk soros porton kommunikalni"Magyarul:
Talakoztam mar olyan kinai fostalicska cuccal, amivel soros porton kellett kommunikalni, es aminek a dokumentacioja chart irt, de valojaban 16 bitet ertett alatta. De nem is wchar volt. Oruletbe kergetett, mire rajottem, hogy gyakorlatilag ugy kell kezelni, hogy minden ertelmes char utan odab@szok meg egy ureset, es akkor fog rendesen mukodni. Na ERRE mondtam azt, hogy a char az char, mindig 8 bit, minden szartol fuggetlenul, csak nehany nagyon specialis esetben van olyan, hogy egy-egy eszkoz mashogy kezeli. Attol meg 1 byte az 8 bit mindenben, es egy char az 1 byte mindenhol, sehol nem irtam olyat, hogy nem.Amugy a tippem az, hogy eredetileg wchar volt, hogy mukodjon az azsiai karakterekkel (azert erre tippelek, mert az inicializalo parancsban kotelezo volt kommunikacios nyelvet megadni - angol, mandarin, 2 byte-ban), aztan a nem kinai implementaciot is arra epitettek, csak uber tre modon, a dokumentacioba meg persze errol basztak irni barmit. Tehat a char az char volt, 8 bit, mint mindig, csak eppen megse, mert ahhoz, hogy a gep felfogjon barmit es ne hulyeseget csinaljon, minden charhoz kettot kellett atkuldeni.
"Programozó vagyok. Ez azt jelenti, hogy amit leírok, megtörténik." :D “The only valid measurement of code quality is What-The-F**ks/Minute.” - Robert Martin
-
coco2
őstag
-
pmonitor
aktív tag
válasz jattila48 #16450 üzenetére
Igen. Pl. itt a FindFileC.exe-t pontosan így készítettem(goto egy sincs benne ). Tehát van a TC, a FindFile és a FindFileC. A TC a leglassabb. A másik kettő sebessége megfelelő(kb. egyforma). Mondjuk hozzá kell tennem, hogy a C#-os FindFile.exe-t is C stílusban írtam(az OOP alapelveit felrúgva). Viszont mióta a C-ben készült változat megvan, azóta azt használom, mert egyrészt 2 kilóval rövidebb a C#-osnál(azért ez 10 kiló körüli programnál jelentős eltérés), másrészt nem kell hozzá .Net. Ja, és a C-ben írt vátozatnál van "Tallózás...", és így is kisebb a mérete.
A kis mérettel lapcsolatban meg itt van egy 29 byte-os "Hello world!!!" program.
[ Szerkesztve ]
http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php
Új hozzászólás Aktív témák
● olvasd el a téma összefoglalót!
- Elado jbl 200tws bluetooth fullhalgato!!!!
- Fallout 76 DIGITÁLIS KÓD XBOX SERIES/ONE/PC
- Eladó PS4 játékok
- ACER PredatoR Triton 16" 3.2k 165hz Intel Core Ultra9 32GB DDR5 2TB NVIDIA RTX4070 8GB,beszamitas is
- AKCIÓ!!! A tökéletes GF! MSI GF63 Thin 11UD i7-11800H 16GB 512GB Nvidia RTX 3050 Ti Gar:2024.08