Thrift serwer w watku wysyła dane do klienta

Zainteresowałem się trochę tematem Thrift obejrzałem sobie przykład kalkulatora
I w przyrządzie jest wszystko jasne klient łączy , coś oblicza a potem rozłącza

    transport->open();

    client.ping();
    cout << "ping()" << endl;

    cout << "1 + 1 = " << client.add(1, 1) << endl;

    Work work;
    work.op = Operation::DIVIDE;
    work.num1 = 1;
    work.num2 = 0;

    try {
      client.calculate(1, work);
      cout << "Whoa? We can divide by zero!" << endl;
    } catch (InvalidOperation& io) {
      cout << "InvalidOperation: " << io.why << endl;
      // or using generated operator<<: cout << io << endl;
      // or by using std::exception native method what(): cout << io.what() << endl;
    }

    work.op = Operation::SUBTRACT;
    work.num1 = 15;
    work.num2 = 10;
    int32_t diff = client.calculate(1, work);
    cout << "15 - 10 = " << diff << endl;

    transport->close();

Ja bym chciał zrobić tak aby serwer sterował przepływem danych

• klient się łączy
• klient do serwera: rozpocznij wysyłanie danych
• serwer uruchamia watek i co 50ms wysyła bufor std::vector<uint8_t> buf(256x128)
• klient odbiera dane std::vector<uint8_t> buf(256x128)
• klient odbiera 1024 porcji danych (razem 32MB)
• klient się rozłącza

Czy to jednak klient powinien sterować przepływem ?

std::vector<uint8_t> buf(256x128);
for(int i = 0 ; i < 1024; ++i)
{
   // 
   client.getFrame(buf); 
}

I podstawowe pytanie czy Thrift nadaje się do tego co che zrobić ?

Moim zdaniem zbyt niskopoziomowo patrzysz, zupełnie niepotrzebnie

Postudiuj pik defincji usługi, na wyższym stopniu abstrakcji niż dzióbanie bajtów, są tam formalne ujęcia na różne struktury danych, odpowiednik tablicy bajtów też (choć sądzę ze to chore)
A tak w ogóle, właśnie chodzi o to, aby twoje mityczne "Frame" zdefiniować w języku nie jako blok głupich bajtów, dokładnie o to chodzi w Thrifcie.

M.in.
https://thrift.apache.org/docs/idl.html

Postudiuj to demo z odejmowaniem, ok, ale potem myślowo się od tego uwolnij i zdefinciuj swoją usługę posługując się legalnym użyciem tego IDL

Adamek Adam napisał(a):

I podstawowe pytanie czy Thrift nadaje się do tego co che zrobić ?

Chcesz źle zrobić / być może sie nie nadaje.
Tym jsonem z innego postu chciałes wysyłać 32MB binarnych danych ???

@ZrobieDobrze pytania dotykają jednego urządzenia embedded które ma różne rodzaje danych i zostało to zrobione przez różne zespoły i udokumentowane w różnych technologiach , cześć w Word a cześć w Spring REST Docs. Dziękuje za linka

Osławiony Json+HTTP został wykorzystany do:

• pobierania przez klienta informacji o stanie urządzenia (proste struktury zawierające proste typy danych np. ile MHz w aktualnej chwili jest ustawione na generatorze albo temperatura urzadzenia )
• pobierana przez klienta listy zapisanych pomiarów (lista struktur z prostymi danymi)
• klient może sterować zdalnie urządzeniem np. GET /MHz/inc albo GET /MHz/dec zwiększają parametr MHz urządzenia

Dodatkowo są dane binarne w postaci strumienia danych std::vector<uint8_t> buf() [ wysyłane w czasie rzeczywistym z częstotliwością 20Hz + opis co jest w tych danych w postaci struktury.
I to zostało zrobione na zwykłym socket protokołem własnym, dłubanie w bajtach i bitach wiec jest to koszmar :D

Strasznie jest to strasznie zrobione, i ja właśnie szukam takiego spojrzenia na problem z trochę wyższego poziomu abstrakcji.
Nie chce miec kilku dokumentacji , albo dokumentację nie spójna z tym co jest w kodzie. Wstepnie to Thrift wydaje sie idealny ;)
Tworzymy opis i generujemy dla c++ i Android , i powinno być zawsze spójne

Opisanie w Thrift tej cześć która jest teraz w HTTP+JSON nie stanowi problemu, zastanawia mnie jednak jak transmitować taki strumień raw-video.

Adamek Adam napisał(a):

zastanawia mnie jednak jak transmitować taki strumień raw-video.

Nie wiem.
Może jak starsze wersje FTP (te nielubiane bo źle przechodza przez firewall), w jednym strumieniu komendy / dialogi, w drugim głupie bajty. To drugie nie Thrift

Aha, w mojej reklamówce thrifta nie podkresliłem, że ma przemyslane, jak zapewnić wpólpracę, gdy po obu stronach będzie starsza / nowsza wersja protokołu (jesli rozwój protokołu jest zgodny z zasadami)

Zastanawia mnie taki koncept uzycia Thrift, klient po podłączeniu do serwera uruchamia serwer (są dwa serwery)

1. KLIENT łączy się do serwera: Moj IP to 192.168.11.8 słucham na porcie 1234
2. SERWER nawiązuje połączenie z 192.168.11.8:1234 i wysyła strumień danych RAW w nieskończonej pętli

Ten dodatkowy serwer jest tylko po to aby to serwer mógł sterować przepływem danych RAW , wszystko co nie jest RAW transmitowane by było na pierwotnym połączeniu KLIENT-SERWER (klient odpytuje serwer)

Thrift jest m.in. po to, żeby wspierać komunikację między procesową. Pamiętam, że raz pisałem taki wrapper który miał za zadanie komunikować grę z takim jednym programem. Po prostu zamiast wykonywać IPS na plikach czy jakoś tak, to owrapowujesz dwa interfejsy(tych dwóch programów) i ten Thrift genereuje Ci cały kod, który odpowiada za komunikację. Tyle co pamiętam sprzed paru lat.
Nie wiem czy można było lepiej czy gorzej to zrobić, byłem juniorem i robiłem co mi kazali, ale faktycznie działało i szybko można było to zrobić.