heby wrote:

> On 29/12/2019 19:32, jacek pozniak wrote:
> >> Nie da się wysłać "ramki" w TCP. To jest ograniczenie i ficzer
> >> protokołu. Do wysyłania ramek jest UDP.
> > Czepiasz się słówek.
>
> Obawiam się że to jest znacznie większa różnica niż tylko słówko.
>
> > Urządzenia komutujące operują na warstwie IP lub
> > podobnej.
> > Raczej nie ciachają Twojego strumienia w dowolnym miejscu.
>
> Ciachają, tylko że te ciachnięcia w przypadku strumienia to tylko
> opóźnienia odczytu i zachwoania funkcji read po stronie odbiorcy.
>
> > Przynajniej tak
> > mi się wydaje.
>
> Ogólnie strumień nie jest w zasadzie ciachany. Po prostu bajty
> przychodza jeden po drugim i to jak zostały wygenerpowane na stacie
> (przerwy, długości zapisów itd itp) nie ma wpływu na to jak zostaną
> odebrane.
Strumień, o ile nie przesyłasz po RS232, JEST ciachany, przy nadawaniu bo
jest obudowywany w ramki IP, po 1400 bajtów lub miej, jeśli socket uzna, że
już się nazbierało dość danych do wysłania lub jakaś tam przerwa w napływie
danych jest.
Jeśli te dane się zmieszczą w 1400 bajtach to raczej przyjdą w jednym
kawałku bo do rozmiaru ramki IP są zazwyczaj dostosowane pozostałe elementy
infrastruktury.


>
> Nadajnik wysyła coś i robi przerwę a po stronie odbiorcy przylatuje
> posklejane albo pocięte w innych miejscach. Strumień jest strumień,
> liczy się tylko kolejnośc bajtów i tylko to jest zagwarantowane,
> zależności czasowe znikają po wielokrotnym enkapsulowaniu. A modbus
> wymaga zależności czasowych.
Mówisz tu o pryncypiach ale wątek jest o konwerterze, który został wymyślony
prawdopodobnie do zastosowań Modbus.


Konwerter działa, wykorzystuje TCP, i raczej nie ma tu mowy o robieniu
jakichś przypadkowych przerw pomiędzy bajtami.
Po prostu on wysyła całe zapytanie, prawdopodobnie w ramach jednego segmentu
danych i z konwertera po drugiej stronie wychodzi tak samo.
Konwertery nie wprowadzają, żadnego narzutu, stosowałem w bezpośredniej
współpracy konwertera ze skryptem bashowym; transmisja szła poprzez jakieś
telewizje kablowe czy coś podobnego.

Takie zachowanie powoduje, że jest on przeźroczysty dla Modbusa (no moze
opóźnienia większe mogą się zdarzyć ale to nie narusza protokołu)

>
> To jest właśnie główna róznica z protokołem UDP. W UDP masz pewnośc że
> dostaniesz dane w "ramce" w takiej formie jak ją wysłałeś. W TCP ramek
> nie ma, jest ciągle kapiący strumień bajtów, jeden po drugim, bez
> żadnych dodatkowych informacji.
Może w tych konwerterach (ACT-2000) można ustawić aby chodziło po UDP ale
nie stosowałem bo nie daje gwaranci dostarczenia danych.


--
jp

www.flowservice.pl
www.flowsystem.pl