- Canon MILC: EOS R és M topik
- AMD Navi Radeon™ RX 9xxx sorozat
- CPU léghűtés kibeszélő
- Autóhifi
- SSD kibeszélő
- Hálózati kábelek és szerelésük
- Kormányok / autós szimulátorok topikja
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- Amazon Kindle
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
-
PROHARDVER!
Új hozzászólás Aktív témák
-
jattila48
aktív tag
-
jattila48
aktív tag
Próbáld meg a BYTE típust, ami nyilván egy typedef. Ez biztos, hogy 8 bites, bármelyik platformon. Már ha létezik BYTE. Ha nem, akkor csinálsz, platformtól függően. 8 bites alap típus biztos, hogy van bármelyiken. A #pragma pack(1) (meg a __packed__) itt nem alkalmazható, mivel az a struktúra tagok alignálására vonatkozik, alaptípusokra nincs hatása.
Olyan pedig nincs, hogy a C nyelv char típusának bithossza attól függjön, hogy a rendszer vagy a fordító ázsiai, vagy más (mármint ha ugyanarról a rendszerről, pl. Window-ról, és ugyanarról a fordítóról beszélünk). Ázsiai nyelvek nyilván nem 1 byte-os karaktereket használnak, de erre a C-nek külön típusa (pl. wchar) van. Amúgy meg szerintem nyugodtan használd az unsigned char-t mint byte-ot, ma már nem valószínű, hogy van ettől eltérő platform. -
jattila48
aktív tag
Sziasztok!
Írtam egy LOCAL_SYSTEM jogosultsággal futó Windows service-t, ami adott esetben alacsonyabb jogosultságú klienst személyesít meg ImpersonateLoggedOnUser API fv.-nyel. A megszemélyesítés szintje SecurityDelegation. A Microsoft dokumentáció szerint ez esetben a megszemélyesített kliens jogosultságaival férhetek hozzá a securable object-ekhez (pl. file-ok). Ez idáig rendben van, de úgy tűnik, megmaradnak a LOCAL_SYSTEM jogosultságaim is, vagyis hozzáférhetek a kliens által egyébként nem elérhető file-okhoz is. Kérdésem, hogy ez így rendben van-e, mert a dokumentáció szerint a megszemélyesítés egyben önkorlátozás is, hogy a megszemélyesített thread ne férjen hozzá magasabb jogosultságot kívánó objectekhez. Esetleg a SecurityDelegation szint miatt van ez így?
-
jattila48
aktív tag
válasz
martonx
#13029
üzenetére
Nem vergődök, csak egyszerűen érdekel ez a kérdés. Ha vergődésnek ítéled, egyszerűbb, ha nem válaszolsz. Nem egyszerűbb adatbázist használni, mert ez egy önmagában kompakt program, egyszerű konfiggal, és nem szeretnék még külön adatbázist is telepíteni/konfigurálni hozzá.
.Net-et nem használok, és nem is akarok.
Az OS/file-rendszer belső működése érdekel, mi a különbség Windows és Linux között (ebből a szempontból), Az MS miért írja, hogy a ReplaceFile atomi ha valójában nem egészen az, illetve miért javasolja a TxF helyett ezt használni (ha az meg valóban atomi). Igazából még most sem vagyok teljesen biztos benne, hogy a ReplaceFile nem atomi abban az értelemben ahogy írtam, szemben a Linux rename-mel. Az OK, hogy a Linuxban mindössze az i-node hivatkozást kell átírni (és ezért lehet valóban atomi a rename), azt nem tudom, hogy az NTFS-ben erre miért nincs lehetőség (nem ismerem az NTFS-t), mikor abban is van hard link. Márpedig ha van hard link, akkor a ReplaceFile lehet valóban atomi.Ui.: kérem, hogy ne alternatív megoldásokra tegyetek javaslatot, azt magam is meg tudom oldani (pl. mutex szinkronizálással), hanem ezt a kérdést próbáljátok megválaszolni. Már persze csak az, aki nem érzi vergődésnek. Ha annak érzed, akkor ne fáraszd magad (meg mást sem) a válasszal.
Köszönöm! -
jattila48
aktív tag
válasz
bambano
#13026
üzenetére
Vagy lehet, hogy a Linux-on csak egy átnevezés van a Windows-on meg kettő? Itt lehet a kutya elásva? Ahogy írtad a Linux-on i-node hivatkozásnak számít a nyitott handle, ezért akkor is folytatódhat az ezzel megkezdett olvasási művelet, ha egyáltalán nincs file név bejegyzés erre az i-node-ra? Windows-ban biztos, hogy keletkezik egy A.tmp név bejegyzés valószínűleg azért, hogy a már nyitott handlékkal folytatni lehessen a megkezdett olvasásokat.
-
jattila48
aktív tag
válasz
bambano
#13026
üzenetére
Ez szerintem pontosan így működik Windowson is. Nem i-node van, hanem valami más struktúra, de Windows-on is csak annyi az átnevezés (ugyanazon a volume-on), hogy az új név bejegyzés a régi file-t leíró struktúrára hivatkozik. Ezt kipróbáltam, a régi file-ra megnyitott handléval zavartalanul lehetett folytatni az olvasást, természetesen a régi file-ból (ami A.tmp-re lett átnevezve). Az is igaz, hogy egy másik thread vagy az előző tartalmat, vagy az újat tudja olvasni, inkonzisztens file tartalom nincs. Az olvasásra történő file megnyitással lehet baj, amikor az első átnevezés már megtörtént, a második még nem. De ez logikailag ugyanúgy fellép a Linux esetében, hiába maradnak meg az i-node-ok. A Linux is két átnevezést kell hogy végrehajtson, ezek között pedig ugyanúgy köztes állapot van, amikor az A-t már nem lehet megnyitni, mivel már a neve nem létezik.
-
jattila48
aktív tag
Ugyanakkor az MS nem javasolja a TxF használatát, helyette pl. a ReplaceFile-t. Most akkor mégsem váltható ki a TxF ReplaceFile-lal? [Alternatives to using Transactional NTFS]
Linuxban a rename valóban atomi, míg a Windowsban a ReplaceFile nem? Ugyanazt a problémát kell megoldani. A Linuxban ez hogy történik? A file rendszerben van erre egy belső szinkronizálás? Windowsban miért nincs, vagy miért nem lehet? Honnan tudjuk, hogy a Windowsban nem atomi a ReplaceFile abban az értelemben amit írtam (nincs kívülről megfigyelhető köztes állapot)? Hogy lehetne tesztelni?
Kísérleteztem a ReplaceFile-lal, és szerintem a következőképpen működik:
Legyen A a helyettesítendő file, B pedig amivel helyettesítjük. Mindkettő ugyanazon a volume-on van.
1. Átnevezi A-t A.tmp-re (vagy valami hasonló temporálisra). Az A file-t nem mozgatja, csak a neve változik (Linuxban az i-node marad ugyanaz), ezért az A-ra már nyitott handlékkal zavartalanul folytatható az olvasási művelet. Ez az a pont, ahol az A nevű file-t nem lehet megnyitni, mert ilyen név már nem létezik. Ez lenne a kívülről megfigyelhető köztes állapot, amikor másik thread nem tudja megnyitni A-t. Az A.tmp-t nem lehet megnyitni.
2. B-t átnevezi A-ra. Szintén nem mozognak file tartalmak, csak a név változik (i-node marad).
3. Az A-ra megnyitott handlék bezárásakor az A.tmp törlődni fog.Tehát a két átnevezés között van a köztes állapot, amikor A-t nem lehet megnyitni. Linuxon feltehetőleg logikailag ugyanígy működik a rename.
-
jattila48
aktív tag
válasz
bambano
#13021
üzenetére
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.
Pontosan ezt akarom. A kérdés az, hogy Windowsban lehet-e ezt atomi módon megtenni. Mert abban a műveletben, hogy "a temporális fájlt átnevezed az eredetire" lehet kívülről megfigyelhető köztes állapot (az eredeti file név nem létezik). Linuxban biztos, hoy nem lehet ilyen?
-
jattila48
aktív tag
A file sharing flagek nem okoznak problémát, azokat tudom kezelni.
Nem IPC re használom a file-t, hanem közönséges konfig file-ként (amibe időnként visszaír a program).
A ReplaceFile-nál számomra "zavaró" köztes állapot csak az lehet, hogy a másik thread nem tudja olvasásra megnyitni a file-t, mert annak a neve (nem a file maga) abban a pillanatban már nem létezik (temporálisra lett átnevezve). Ha sikerül megnyitni, akkor biztosan konzisztens tartalmat tudok olvasni (vagy a régit, vagy a már módosítottat), sőt a ReplaceFile előtt megkezdett, de még be nem fejezett olvasási művelet is a régi konzisztens tartalmat olvassa (akkor is, ha a ReplaceFile közben már befejeződik). Tehát csak az OpenFile-ban lehet hiba. Arra gondoltam, hogy ez esetben rövid Sleep után újra megpróbálom (időt hagyva a ReplaceFile befejeződésére), és ha akkor sem sikerül, akkor a file valóban nem létezik, és feladom a próbálkozást. Mutexet és egyéb szinkronizációt azért nem akarok használni, mert éppen a szóban forgó konfig fájlból olvasnám ki a további szinkronizációhoz szükséges mutex nevét. -
jattila48
aktív tag
válasz
bambano
#13016
üzenetére
Ez nem jó megoldás, mert megnyitni ugyan meg tudja, de akkor már olvasni is szeretne belőle. A cél az, hogy ha meg tudta nyitni, akkor vagy az eredeti (még ReplaceFile előtti) állapotot lássa, vagy az újat, de sem megnyithatóság, sem olvasás szempontjából ne lásson köztes állapotot.
-
jattila48
aktív tag
Köszönöm a választ. Én is tartok tőle, hogy olyan értelemben nem atomi a művelet, hogy blokkolná az OS-t, és valóban gondot okozhat, hogy több magon hardveresen (context switching nélkül) több szál is futhat.
A másik thread file megnyitásával kapcsolatban nem a sharing flagekre gondoltam, hanem hogy 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.
A posix rename különbözik ilyen szempontból?
TxF-et nem akarok használni, az MS sem javasolja: [link] -
jattila48
aktív tag
A Windows ReplaceFile API függvényével kapcsolatban érdekelne, hogy az mennyiben tekinthető atomi műveletnek. Atomi művelet elvileg az, amit nem lehet megszakítani. Vagy teljesen végrehajtódik, vagy egyáltalán nem. 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. 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? Ekkor ugyanis lehet, hogy a másik thread nem fogja tudni megnyitni a file-t. 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. Mi a véleményetek/tapasztalatotok ezzel kapcsolatban?
-
jattila48
aktív tag
A tényleges feladatról pedig semmit nem írt a kérdező. Számomra úgy tűnt, hogy a hálózati kommunikáció okoz neki gondot. Erre javasoltam a C programozást. A 150-200 kliens pedig egyáltalán nem sok. Ha 10000-ekről lenne szó, akkor is házi C programozást javasolnék (sőt főleg akkor), csak természetesen nem blokkolt, UDP protokoll thread-pool-lal. Ha pedig valamiféle hálózat felügyeletről van szó, akkor lehetőleg SNMP közvetlen ethernet felett, de erre már tényleg vannak kész megoldások.
-
jattila48
aktív tag
Értem én, hogy cinikus vagy a földig hajló respekt szmájliddal, de hidd el, hogy a legegyszerűbb hálózati TCP kliens-szerver kommunikácó az megvan egy napi munkával (igaz, több mint 20 éve nyomom a hálózat programozást). Keress rá interneten, pl. "multithreaded TCP server in C"-vel. Az adakinyerés és szerver oldali megjelenítés persze más kérdés, arról semmit sem írt a kérdező. Erre írtam, hogy azt esetleg lehet C programból szkriptek hívásával megoldani. Ha tényleg csak időnként küldenek a kliensek valami státusz jelentést (pl. 10 másodpercenként), akkor a 100-150 kliens az egyáltalán nem rengeteg, sőt.
-
jattila48
aktív tag
Nem tudom miért vagytok odáig egy kis programozástól. Ez tényleg egyszerű feladat, nekem kb. 1 napi munka lenne. Számtalan példát találtok kliens-szerver TCP kommunikációra. Az adatkinyerést meg lehet oldani akár szkriptek hivogatásával is. A különböző opensource vagy fizetős megoldások telepítése, megismerése, konfigurálása, szerintem jóval nagyobb feladat. Amit a kérdező leírt, nem tűnik túl bonyolultnak. Nem kell rögtön ágyúval lövöldözni. Lesz egy kis időm, lehet beírom ide a C kódot.
-
jattila48
aktív tag
válasz
McSzaby
#8928
üzenetére
Akkor szerintem sima blokkolt TCP, esetleg thread pool-lal. Ha nincs egyszerre sok kapcsolat, és a kliensek viszonylag ritkán kapcsolódnak, akkor a thread pool sem szükséges. Lehet minden kapcsolathoz új thread-et indítani, ami a kliens feldolgozása után leáll. Ez a legkevésbé hatékony módszer, de a legegyszerűbb is. Ez is elég lehet neked.
-
jattila48
aktív tag
válasz
McSzaby
#8926
üzenetére
Nem tűnik bonyolult feladatnak, mondhatni szokásos. Én C-ben írnám meg az egészet, a szerver és kliens részét is. A szerver, ha sok klienstől, de kis csomagszerű adatforgalmat fogad, akkor UDP-vel kommunikálhat. TCP-vel akkor, ha viszonylag állandó a kapcsolat, és stream-szerű az adatforgalom. Szerintem neked az UDP lesz megfelelőbb. Ha UDP-t választasz, és valami titkosítás/hitelesítés is kell, akkor azt magadnak kell megoldani. Ez sem bonyolult, kész algoritmusokat találsz, pl. AES, RC4/MD5. UDP esetén szerintem blokkolt socket kezlést alkalmazhatsz, thread-pool-lal. Ha a TCP-t választod, akkor titkosítás/hitelesítés-re használhatod az OpenSSL-t, bár ez szerintem kicsit túllövés. Ha sok kliensed van, akkor TCP-nél a nem blokkolt socket kezelés hatékonyabb lehet, de egy kicsit bonyolultabb programozni. Szkripteket hívogatni és SSH-t kezelni, biztos, hogy nem lesz elég hatékony. Persze, ha csak néhány száz kliensed van, akkor még ez is működhet.
Új hozzászólás Aktív témák
Hirdetés
● olvasd el a téma összefoglalót!
- HP Spectre x360 Érintős Hajtogatós Laptop Tab 16" -60% i7-1360P 32/2TB Intel Arc A370M 4GB UHD OLED
- Szép! Lenovo Thinkpad T14s G2 Üzleti "Golyóálló" Laptop 14" -60% i5-1135G7 4Mag 16GB /512GB FHD IPS
- Samsung Q80T 55" QLED - 4K 120Hz VRR / FreeSync / HDMI 2.1
- ÚJ HP ENVY 17 Nagyképernyős "Kis Gamer" Laptop -45% 17,3" Brutál i7-13700H 16/1TB Iris Xe FHD IPS
- Legion Go 8APU1
- ÁRGARANCIA!Épített KomPhone i7 14700KF 32/64GB RAM RTX 5080 16GB GAMER PC termékbeszámítással
- Bowers/Wilkins PX8 fejhallgatók (dupla Bluetooth eszköz csatlakoztatása!) - ELKELTEK
- PlayStation Network Card (PSN) ajándékkártyák, egyenesen a Sony-tól!
- Napi 1000 -ft tól elvihető RÉSZLETFIZETÉS BANKMENTES MSI Cyborg 15 A13VE
- Csere-Beszámítás! RTX Számítógép játékra! I7 6700K / 32GB DDR4 / RTX 2060 / 500GB SSD
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest