Ú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
● ha kódot szúrsz be, használd a PROGRAMKÓD formázási funkciót!
- PlayStation 5
- Visszagyorsítja a Windows visszalassulását a GeForce driver gyorsjavítása
- Székesfehérvár és környéke adok-veszek-beszélgetek
- Kínai és egyéb olcsó órák topikja
- Okos Otthon / Smart Home
- BestBuy topik
- Vezeték nélküli fülhallgatók
- Csavard fel a szőnyeget! - Xiaomi Vacuum 5 teszt
- OLED TV topic
- Ne már! Drágább lesz a GPU a memóriapánik miatt?
- További aktív témák...
- Újszerű bivaly Lenovo Thinkpad T16 gen3 (13.gen Core Ultra 7 32Gb DDR5 1 Tb SSD) MAGYAR 30 hó GARI!
- Bivaly Lenovo T14 gen5 (Core Ultra 7 32Gb DDR5 1 Tb SSD) laptopom eladó 30 hónap gyártói garanciával
- Bomba ár! Dell Latitude 3410 - i3-10110U I 8GB I 256SSD I HDMI I 13,3" FHD Touch I Cam I W11 I Gari
- Bomba ár! Dell Latitude E5550 - i5-5GEN I 8GB I 128SSD I 15,6" FHD Touch I HDMI I W10 I Cam I Gari!
- Bomba ár! Dell Latitude E5540 - i5-4GEN I 4GB I 240SSD I Nvidia I 15,6" FHD I Cam I W10 I Garancia!
- Samsung UE75DU7172U 189 cm / 75 4K UHD Smart TV 6 hó garancia Házhozszállítás
- BESZÁMÍTÁS! ASUS PRIME H510M i5 10400F 16GB DDR4 512GB SSD RX 6600 XT OC 8GB CHIEFTEC Libra 600W
- GYÖNYÖRŰ iPhone 13 Pro 128GB Graphite -1 ÉV GARANCIA - Kártyafüggetlen, MS3082
- MacBook felváráslás!! MacBook, MacBook Air, MacBook Pro
- ÚJ Lenovo ThinkPad X13 Gen 5 - 13.3" WUXGA IPS - Ultra 5 135U - 16GB - 512GB - Win11 - 2,5 év gari
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Laptopműhely Bt.
Város: Budapest