Hirdetés
- Poco X8 Pro Max - nem kell ide sem bank, sem akkubank
- Xiaomi 15T Pro - a téma nincs lezárva
- Yettel topik
- Milyen okostelefont vegyek?
- Külföldi prepaid SIM-ek itthon
- iPhone topik
- Google Pixel topik
- VoLTE/VoWiFi
- Nagy aksival és erős hardverrel megjött Magyarországra a Poco X8 Pro és Pro Max
- Nemzetközi vizekre evezett a Realme GT 7 és GT 7T
Ú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.
-
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.
-
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!
- Egyre inkább szoftverrel segítene a Core CPU-k teljesítményén az Intel
- Reklámblokkolók topikja
- Saros (PS5)
- Poco X8 Pro Max - nem kell ide sem bank, sem akkubank
- LG LCD és LED TV-k
- Xiaomi 15T Pro - a téma nincs lezárva
- Futás, futópályák
- EAFC 26
- Apple MacBook
- One otthoni szolgáltatások (TV, internet, telefon)
- További aktív témák...
- MacSzerez.com - 2021 MacBook Pro 16" Retina / M1 Max / 32GB RAM / 1TB SSD / Asztro
- SteelSeries Arctis Nova 7 Wireless Bolti ár:75k INGYEN FOXPOST
- Újszerű SteelSeries Arctis 7 2019 Edition Wireless Bolti ár:55k INGYEN FOXPOST
- Garmin Forerunner 970 Bontatlan
- CoreI5,13600KF,14/20/GIGABYTE,B760M-DS3H,KINGSTON,DDR4 32GB,RTX5060TI 16GB/2Tb T.hely/GARI/Win11!
- Apple iPhone 12 Pro Max / 128GB / Kártyafüggetlen /12Hó Garancia / Akku: 87%
- Dell Latitude 5410 - 14", Core i5 10210U, 8-16GB RAM, SSD, jó akku, számla, 6 hó gar
- Workstation bazár - Dell, Lenovo - számla, 6 hó garancia
- Lenovo T480S i5 8350U, 16GB RAM, 256GB SSD, jó akku, számla, 6 hó gar
- Tablet felvásárlás!! Samsung Galaxy Tab A8, Samsung Galaxy Tab A9, Samsung Galaxy Tab S6 Lite
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest