- Hívószám-hamisítás
- Magisk
- One mobilszolgáltatások
- iPhone topik
- Íme az új Android Auto!
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Szívós, szép és kitartó az új OnePlus óra
- Samsung Galaxy Fit 3 - keveset, de jól
- Honor Magic6 Pro - kör közepén számok
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
Új hozzászólás Aktív témák
-
-
dqdb
nagyúr
A compatibility page akkor érvényét vesztette, amikor tavaly lejárt a VS2015 kibővített támogatása is. A VS2017 és VS2019 még az aktív támogatási időszakban vannak, ezeknél lehet elvárásod, azonban ha a VS2015-nél valami eltörik, akkor IJ, ezek a dátumok végig szerepeltek a támogatási roadmapben.
-
dqdb
nagyúr
C# esetében miért ragaszkodsz a 2015-höz? Ha akad VC14-et igénylő interop kód, amit macerás portolni, akkor oké, de amúgy önszívatás a régi .csproj formátumon maradni, sokkal lassabb NuGet csomagfrissítéssel szívni és a .NET Core 2.0 és frissebb támogatás teljes hiányáról ne is beszéljünk.
A VS2015 támogatása már egy éve lejárt, ezért nem tolja az ember képébe a Microsoft oldala, de ettől függetlenül a Community és többi változathoz tartozó ISO elérhető innen.
-
sztanozs
veterán
Ha "rendesen" leállítod, akkor a szerver vagy a kliens dob a túloldalra egy FIN csomagot. Ezzel értesíti a túloldalt, hogy a csatornát be kell zárni. Sztenderd módon a túloldalnak válaszolni kell egy ACK csomaggal és küldenie szintén vissza egy FIN csomagot amit a kezdeményező oldal lenyugtáz egy ACK-val. Tehát, ha normál módon (Listener.Close vagy Client.Close-zal) zársz le egy kapcsolatot, akkor a túloldal értesülni fog róla, hogy bezárod, így nem tartja nyitva a csatornát.
Alapból a TCP protokoplban nincs keepalive ping, szóval, ha kézzel vezérled a TCP kapcsolatot, akkor simná le tudod lőni a listener-t és újra felhúzni, feltéve, ha vissza tudod állítani a TCP stack-et a lezárást megelőző állapotba (tehát tudni fogod, milyen porton kivel kommunikál). -
joysefke
veterán
Nem értem hogy mi a probléma meg milyen token referenciáról beszélsz.
A token egy struct, ami tartalmazza az őt létrehozó CTS referenciáját. Te ezt nem látod, mivel a token structon a cts-re mutató referencia nem publikus. (pont ez a pattern lényege, hogy ne lehessen össze vissza cancellelni csupán a cts birtokában)
A cancel pedig kétféle módon propagálódik:
1, Te manuálisan a saját magad függvényében ellenőrzöd, hogy történt-e cancel:
bool token.IsCancellationRequested vagy
void token.ThrowIfCancellationRequested()2, Valamelyik framework API akinek Task létrehozásakor átadtad a tokent ellenőrzi a token állapotát és saját maga rakja az általa felügyelt Task állapotát Cancelled-re. A TaskFactory gondolom egy ilyen valami. (nem ismerem a TaskFactory-t)
-
joysefke
veterán
A TaskFactory-val van a problémád vagy magával a CancellationTokenSource => CancellationToken mechanizmussal?
A cts -token egy távirányítós bomba. A bomba a Token a távirányító pedig a CancellationTokenSource. a kliens kódnál a távirányító (CTS) és a távirányítóhoz tartozó bombát átadja a hívott metódusnak a Token formájában. Te mindig a CTS-t hozod létre konstruktorral, a Tokent a CTS propertijeként kapod meg.
Amikor megunod a várakozást, robbantod a bombát a távirányítóval.
A példakódot lefuttattam, ott ha AggregateException jött jelzi azt, hogy a CTS-en meg lett hívva a cancel.
-
martonx
veterán
Nagyon helyes, hogy régi elavult dolgokat (ami már új korában is szar volt, a fent részletezett okok miatt) nem támogatnak.
Ha szerver komponens is kell, akkor használj .Net Framework-öt.Egyébként már annyiszor mondtam: Miért nem használod a hivatalos dokumentációt??? Van ott WCF tutorial is, direkt nem vagyok hajlandó idelinkelni a kézenfekvőt.
-
Keem1
veterán
Eddig fájlokkal dolgoztunk, most jött az ötlet, hogy egységes formátumú XML (XML-RPC) kommunikációra állnánk át.
És az lenne a következő hónapok terve, hogy Linuxra álljunk át. Persze SMB megosztás nyilván ott is játszik, csak hát... Virtuális Linuxon, illetve itthon Raspberry Pi-n egész jól fut a .Net 4.5 és a Core 3.0 kód is.@sztanozs
Ahogy látom, most a Python mindennél népszerűbb volt, pedig azt hittem eddig, hogy a legnépszerűbb nyelv a Java, illetve utána valahanyadik helyen, de nem sokkal lemaradva a C#/.Net. Meg is lepődtem nemrég. -
dqdb
nagyúr
így utólag már mezei file-ok és memória blokkok elegendőek az sql szerver helyett, ami bizony egyszerűbbé teszi a dolgokat - akár hiszed, akár nem.
Tudom, hogy egyszerűbbé tudja tenni a fájlokat használó megoldás az életet, rendszeresen használok ilyet a storage interfész mockolására tesztekben. Persze éles környezetben nem, hiszen a redundancia, rendelkezésre állás kifejezések léteznek, és amíg egy clusterezhető middleware elintézi helyettem az adatok node-ok közötti replikálását, addig egy fájlalapú megoldásnál nekem kellene ezt nulláról lefejleszteni. Nem lehetetlen, csak rettenetesen időigényes, és akármennyi erőforrást is elégetek rá, akármennyi tesztet gyártok hozzá, a saját implementáció kevésbé lesz tesztelve éles szituációban, mint az elterjedt 3rd party megoldások. Vannak esetek, amikor érdemes feltalálni a spanyolviaszt, mert megéri, ez szerintem határozottan nem az.Részemről inkább azt a kérdést tartom nehezen megválaszolhatónak, hogy a c# topikban miért c stuffokat preferálnak a népek?
Én sosem a nyelvhez, hanem mindig feladathoz választok middleware-t, az pedig, hogy miben írták, teljesen irreleváns addig, amíg van hozzá .NET vagy REST API. Így aztán az egyik rendszerünk tipikus telepítése használ Javában, Erlangban és Góban készített middleware-eket (másikban akad Ruby is), miközben a rendszerünk forrása egyetlen sornyi Javát, Erlangot és Gót sem tartalmaz. Nem azért, mert a szivárványos össznyelvi összeborulás volt a cél, hanem azért, mert adott részfeladatra az adott komponenst találtuk a legjobbnak. -
dqdb
nagyúr
Az Iodine támogatja, ezt már sztanozs is jelezte. A másik csak egy egyszerű frontend, elé kell tenni egy rendes webszervert TLS proxynak.
A chrome is, meg a firefox is konkrétan blokkolják, ami nem támogat https-t, legyen az akár csak egy webapi kiszolgáló.
Rossz megközelítés: nem azért kell TLS-t használni, mert a Chrome és a Firefox sír a hiánya miatt, hanem azért, hogy védett legyen a kapcsolat, és ettől mellékesen a Chrome és Firefox boldog lesz. Nem tudom másoknál hogyan van, nálunk már sok-sok éve a fejlesztői rendszerekben is TLS-sel védett minden kapcsolat.könnyű megírni egyébként is
Ja, ha ilyen könnyű összedobni egy skálázható-clusterezhető megoldást, akkor nem szóltam. Kár, hogy a fél világ ezt nem tudja, és Redisre épít, ha cache kell neki. -
martonx
veterán
Szerintem valamit fordítva kezdtél el. Nekem még az se biztos, hogy vágod-e mi a különbség az asp.net core és más asp.net-ek között?
Konzolba kiadsz egy dotnet new web parancsot, majd dotnet run, és már futhat is a load teszt, mókolhatod a kódot, hogy mi hogy legyen optimalizáltabb.
-
joysefke
veterán
Nekem úgy tűnik, hogy
1,
te sessionöket és ezen keresztül szerver -> kliens irányú nyitott NAT-portokat akarsz fenntartani, hogy push üzeneteket küldhess (szerver-> kliens).2,
A két szervered közül gondolom az egyik az valami frontend a usereknek, a másik pedig a backend. A FE és a backend között (nyilván?) nem lesz NAT, és a backend szerver bármikor elérhető a frontended számára.Szerintem az 1,-hez valami külön real time framework kéne, ami kezeli a push üzeneteket. Kell legyen ilyen ASP-hez is.
A 2,-es feladat teljesen más, azt nem is mosnám össze az 1,-gyel.
-
sztanozs
veterán
HTTP alapjában véve stateless protokoll, tehát bontja a kapcsolatot. A HTTP1.1 kiegészítéssel lehet sztenderd http keepalive-ot kapni. Viszont (főleg resource és biztonsági okból) a TCP perzisztencia viszonylag rövid idejű - 5-15 másodperc. Épp ezért főként arra használható, amire kitalálták (sok elemből álló weblap betöltése), nem pedig, amire te használni szeretnéd: fél-egy percenként némi adatot átküldeni.
Ennyi ideig nyitva tartani egy tcp portot sokkal erőforrás pazarlóbb, mint lezárni és újra megnyitni. Hagyd, hogy a network stack dolgozzon, nem jó ötlet túl sok portot egyszerre nyitva tartani (főleg akkor nem, ha nincs rajtuk forgalom).
Új hozzászólás Aktív témák
Hirdetés
● ha kódot szúrsz be, használd a PROGRAMKÓD formázási funkciót!
- Napelem
- Mibe tegyem a megtakarításaimat?
- Rágyúr a macOS-re a 3DMark
- Milyen légkondit a lakásba?
- Gyúrósok ide!
- Counter-Strike: Global Offensive (CS:GO) / Counter-Strike 2 (CS2)
- Fortnite - Battle Royale & Save the World (PC, XO, PS4, Switch, Mobil)
- Előrendelhető a OnePlus Pad 3
- Milyen monitort vegyek?
- Hívószám-hamisítás
- További aktív témák...
- Eladó konfig! Ryzen 7 7800X3D 2TB SSD 64GB DDR5 RX9070XT 16GB!
- Új, makulátlan állapotú Samsung Galaxy Buds FE, fehér, fél év garancia
- Új, makulátlan állapotú Samsung Galaxy Watch7 44mm ezüst, 2 év garancia
- Új, makulátlan állapotú Samsung Z Fold 6 256GB Tengerészkék, független, 2 év garancia
- Használt TP-Link Deco M4 - AC1200 Router (Mesh-ként is használható)
- AKCIÓ! Gigabyte B450M R7 2700X 16GB DDR4 512GB SSD RX VEGA64 8GB CM 690 III FSP 600W
- Szerezd be most az érzékelhető különbséget! Akár 0% THM-re
- Bomba ár! Lenovo ThinkPad L480 - i5-8GEN I 8-16GB I 256GB SSD I 14" FHD I HDMI I Cam I W11 I Gari!
- ÚJ Apple Macbook Air 15,3 M4 10C CPU/10C GPU/16GB/256GB - Ezüst -(2025) - 3 év gari - MAGYAR
- ÁRGARANCIA!Épített KomPhone i5 13400F 16/32/64GB RAM RX 7700 XT 12GB GAMER PC termékbeszámítással
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged