- Hálózati / IP kamera
- Sweet.tv - internetes TV
- A Microsoft feltalálta az olcsó AI-t
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Musk szerint már jövőre itt vannak a Tesla Optimus humanoid robotok
- Otthoni hálózat és internet megosztás
- Synology NAS
- Windows Insider Program
- Milyen routert?
- Bittorrent topik
-
IT café
Új hozzászólás Aktív témák
-
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.
„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár
-
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.
„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár
-
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.
„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár
-
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.
„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár
-
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.
[ Szerkesztve ]
„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár
-
jattila48
aktív tag
Nagyon régi könyv, és sokak szerint talán kicsit idejétmúlt, de nekem az egyik kedvencem:
Niklaus Wirth: adatstruktúrák+algoritmusok=programok. A pascalt ismertni kell hozzá.„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár
-
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?
„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár
-
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][ Szerkesztve ]
„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár
-
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.
„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár
-
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.„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár
-
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?
„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár
-
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.
„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár
-
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.
„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár
-
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.
„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár
-
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!„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár
-
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?
[ Szerkesztve ]
„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár
-
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.„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár
-
jattila48
aktív tag
Akkor ezt hogy érted?
"van par ilyen azsiai borzalom, ahol 16 bit a char alapbol"
Mi az az ázsiai borzalom? A C nyelv char típusának a hossza, a fordító tuldjdonsága.„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár
-
jattila48
aktív tag
Van aki Windows GUI-t Win32 API-ban programozik C nyelven? Van erre külön topik?
„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár
-
jattila48
aktív tag
Ez OK, hogy a dokumentációban a derék kínaiak a char alatt wchar-t értettek. De Coco2 kérdése szerintem a C nyelv char típusára vonatkozott. Az pedig fordító függő, de nem úgy, hogy ázsiai-e vagy nem. Szerintem félreérthető volt a válaszod, én legalábbis félreértettem.
„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár
Új hozzászólás Aktív témák
● olvasd el a téma összefoglalót!
- Kínai, és egyéb olcsó órák topikja
- Hálózati / IP kamera
- Sweet.tv - internetes TV
- Motoros topic
- Milyen notebookot vegyek?
- A Microsoft feltalálta az olcsó AI-t
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Musk szerint már jövőre itt vannak a Tesla Optimus humanoid robotok
- Vodafone mobilszolgáltatások
- RAM topik
- További aktív témák...