Új hozzászólás Aktív témák
-
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).[ Szerkesztve ]
JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
-
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.
-
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.
Én kérek elnézést!
-
sztanozs
veterán
Őőőő, 1p utánajárás:
Iodine includes native support for:
...
- TLS 1.2 and above (Requires OpenSSL >= 1.1.0);
plusz[ Szerkesztve ]
JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
-
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.tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
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.tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
martonx
veterán
A hivatalos dokumentáció: https://docs.microsoft.com/en-us/aspnet/core/data/ef-mvc/intro?view=aspnetcore-3.1
Én kérek elnézést!
-
Keem1
addikt
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.[ Szerkesztve ]
-
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.
Én kérek elnézést!
-
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.
[ Szerkesztve ]
-
-
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)
[ Szerkesztve ]
-
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).JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
-
-
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.
[ Szerkesztve ]
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
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.
[ Szerkesztve ]
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
pmonitor
aktív tag
Az amúgy publikus kódjaimat pontosan ilyen okok miatt nem projektben adom közre, hanem a forrás file--(oka)t, és leírom, hogy hogyan ajánlom kipróbálni. A codeproject.com-os projekteknél járok sokszor úgy, hogy nem működnek.
http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php
Ú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!
- sziku69: Fűzzük össze a szavakat :)
- Yettel topik
- Windows 10
- Samsung Univerzum: Az S23-at is megbabonázta a Galaxy AI
- Diablo IV
- Gaming notebook topik
- Villanyszerelés
- Futott egy Geekbench kört egy új HTC készülék
- Magga: PLEX: multimédia az egész lakásban
- Xiaomi 11 Lite 5G NE (lisa)
- További aktív témák...