Diskuze: TcpClient<>TcpListener komunikace
Neaktivní uživatel:27.9.2016 17:15
Nevím jestli to není moc OOP overkill, ale já bych si vytvořil
abstraktní třídu Message (která nic neobsahuje).
Z ní pak mohou dědit třídy jako ControlMessage nebo TextMessage, které
budou obsahovat vhodné vlastnosti (jak říkáš číslo nebo text). Tyto
třídy pak serializuješ ( Binární serializace vrací bajtové pole) a
odešleš. Na straně příjemce poté deserializuješ do třídy Message, a
uděláš rozhodovací logiku dle typu té Message:
if(message is ControlMessage)
...
else if(message is TextMessage)
...+20 Zkušeností
+2,50 Kč
Erik Šťastný:29.9.2016 10:10
Jo oba co říkáte zní asi dobře 
Druhá otázka je jestli je todle řešení správné. Je v pořádku
to řešit todle řízení a zároveň dotazy na server obyčejnýmy
čísly?
Jednoduchý příklad server bude clientovi posílat aktuální datum když si ho client vyžádá. Jak by měl vypadat takový požadavek? Nejjednodušší mi prostě přijde, že client pošle jen třeba int číslo 1 a server bude v podmínkách vědět (if IncomingRequest == 1, tak poslat zpátky datum). Ale už na první pohled mi to nepřijde moc elegantní řešení zvlášť když bude mít server v řádech stovek funkcí.
Je to zcela standardní řešení.. nemáš tam ale v kodu číslo ale
prostě konstanty.. Máš prostě něco čemu se říká packet protocol a v
něm máš takhle nadefinované jednotliví packety.. tam se ale pak řeší
různé optimalizace, které jsou o binárních operacích atd atd.. 
Je to poměrně rozsáhlá látka..
které bych se ale možná v tvém případě prvoplánově nevěnoval a udělal
to cestou nejmenšího odporu.
Erik Šťastný:29.9.2016 12:26
Tak to, že je to standartní řešení mě celkem těší. Takže základní věci zredukuju na jednoduché integery a na větší záležitosti použiju serializaci třídy jak poradil kolega nahoře.
Hehe Ragnarok Online
Threading na štěstí asi nebudu muset řešit, stačí mi vše synchronní a
requesty odesílat jak za sebou přijdou Ale na tu síťařinu možná mrknul díky za tip
Erik Šťastný:30.9.2016 11:38
Aha tak kecám zjistil jsem, že vlákna budou potřeba pokud nebudu chtít
po každé zprávě ukončovat spojení 
Pokdu to má být něco jako herní server, tak stejně budeš potřebovast
connecitonless přístup Ono
není úplně ideální na long-term věci mít otevřeno 100 connectionu
Erik Šťastný:30.9.2016 15:39
Hmm to bohužel nepůjde, neposílám nic vhodného na UDP, jinak říkáš,
že je lepší když člověk potřebuje TCP, tak ty spojení radši uzavírat?
Já právě to zrovna
přepisoval aby každý client měl spojení dokud se sám neodpojí a ne aby se
co každých x zpráv dělalo nové
Erik Šťastný:3.10.2016 11:27
Nakonec jsem to udělal přesně jak říkáš, z počátku jsem se toho
bál, ale předávat si hotové třídy je mnohokrát "hezčí"
Nicméně se potýkám s problémem deserializace na druhé straně která přijme serializovanou třídu.
Konkrétně jde o vyjímku:
An unhandled exception of type 'System.Runtime.Serialization.SerializationException' occurred in mscorlib.dll
Additional information: Sestavení ConsoleApplication3, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null nebylo nalezeno.Dočetl jsem se na netu, že je třeba aby měli projekty nějaké společné
reference, a ne jen tu stejnou definici třídy, můžete mě prosím navést?
Jestli jsem tě správně pochopil, tak jen napíšu DLL třeba ve kterém
budou definice všech objektů které budu chtít posílat a to DLL bude
používat i server i client, ano?
Erik Šťastný:3.10.2016 14:40
No dokonalost už to běží jak má a vesele si posílám structury Moc děkuji!! Bohužel druhé
řešení ti nedám
ještě jen taková otážečka, myslíš, že je lepší poslat více menších tříd/struktur nebo jednu obrovskou? Hádám, že kvůli TCP je lepší poslat rovnou jednu větší, ne?
Zobrazeno 18 zpráv z 18.