Komunikační protokol – C / C++ – Fórum – Programujte.com

Ahoj,

prosím o konzultaci volby komunikačního protokolu v systému, kde se vzdálená zařízení připojují po síti jako klienti, centrální část zařízení obsahuje server. Používám TCP/IP. Zatím byl navržen komunikační protokol, který sestává z povinné hlavičky (4 znaky identifikace příjemce, 4 znaky identifikace odesílatele, 3 znaky délka dat) a dat avizované délky. Obvyklá délka dat bude několik desítek Bytů. Přenášená data by vypadala takto:

z001j045004Data

Je tento způsob vhodný nebo byste to řešili jinak? Jak?

hu

no teoreticky identifikaci prijemce a odesilatele muzes udelat podle IP adresy (kdyby to nestacilo tak i portu)

Možná by bylo dobré vzít nějaký hotový a zkusit si ho třeba jenom modifikovat.

Třeba Modbus je jednoduchý a snadno si ho přizpůsobíš:

http://home.zcu.cz/~ronesova/bastl/files/modbus.pdf

Pokud nemáš nic proti existujícím protokolům (již zmíněný Modbus nebo třeba Profibus/Epsnet), tak bys měl jednu výhodu - existuje "mraky" funkčního SW, kterým by sis to mohl vyzkoušet a případná kooperace s jinými klienty by mohla být jednodušší.

V případě, že chceš vytvořit svůj vlastní protokol, tak 4 bajty na identifikaci přijemce a odesílatele jsou až moc. Server nakonec budeš mít jeden a klientů asi víc jak 65535 nebude, takže ti stačí 2 a 2 bajty. Ale co bych ti rozhodně doporučoval je číslování paketů (klidně jenom jeden bajt), kdy každá další výzva má o jednu vyšší číslo. To je největší slabina stávajících protokolů, kdy z odpovědi nepoznáš, na který dotaz přišel.

Identifikace: první znak vyjadřuje skupinu klientů. Klienti jsou rozděleni podle daných kritérií do 3 skupin. Dekadické trojčíslí je pak unikátní označení klienta ve skupině. Klientů nebude víc než 1000, ale také jich může být více než 100 v jedné skupině. Naddimenzované, ale požadavky rostou rychle.

Číslovat zprávy mne nenapadlo, spoléhal jsem, že budou doručeny ve stejném pořadí v jakém byly odeslány. Podle jakého klíče to winsock rozdělí na pakety vůbec netuším. U TCP/IP by měly chodit v pořadí ve kterém byly odeslány. Faktem zůstává, že příjemce může dostat zprávu po částech - je nutné opakovaně volat recv a v bufferu aplikace zprávu složit. U Real Time jsem předpokládal, že zařízení, které hodnotu změřilo v datech uvede i čas kdy měření proběhlo.

Z důvodů kompatibility by mi byl nejbližší "Pfeiffer Vacuum Protocol", ten je ale děsně "ukecanej" a neobsahuje identifikaci odesílatele. Předpokládají, že mezi odesláním požadavku  a přijetím odpovědi na RS485 neproběhne jiná komunikace. Provádění kontrol jako CRC, BCC apod. mi příjde nadbytečné, protože kontrolní mechanismy TCP/IP již obsahuje.

IP adresy: pokud klienti si mezi sebou něco přeposílají přes server, odesílající klient nezná IP adresu příjemce, IP adresy klientů v systému zná server. Stejné je to i s čísly soketů. Pokud někteří klienti budou připojeni přes DHCP, je k nezaplacení vědět, že z006 je voltmetr s multiplexerem a hromadou termočlánků v místnosti č.xxx

hu

Ok, pokud máš stovky klientů rozdělených do skupin, tak proč ne. A s tím číslováním to nebylo směřováno na TCP rámce, ale na to, že když pošleš dotaz a nepřijde ti do timeoutu odpověď a ty pošleš jiný dotaz (na jiná data o stejné délce se stejnou identifikací klientů), jak poznáš, že přišla ta správná odpověď a nepřišla ("zatoulaná") odpověď na předchozí dotaz?

Ale pokud je to tak, že co klient to jedna zpráva a nic víc, tak ani to číslování nepotřebuješ a stačí ti ta identifikace klientů.

To cislovanie packetov sa da vyriesit pribalenim nejakeho "opcodu" do packetu (stacil by na to teoreticky jeden oktet), pricom by to bolo len nejake ID co ten packet znamena (napriklad dotaz na teplotu v miestnosti, odpoved na teplotu z miestnosti atd atd atd). Takto by si jednoducho vedel co to je za packet, co ma presne obsahovat a ako s nim narabat.

#1 hlucheucho
Pokud dobře chápu, chceš komunikovat po TCP mezi klienty a serverem. Bohužel neznám pozadí projektu, takže se těžko radí, ale osobně bych zvážil možnost použít něco textové, založeného například na XML.

Prakticky jedinou opodstatněnou výhradou proti použití textového protokolu by byl brutální a neoddiskutovatelný nedostatek výkonu na straně serveru nebo klientů, jinak má binární protokol IMHO samé nevýhody.