Uściślenie protokołu sieciowego

[metiulekm]

W specyfikacji o protokole jest napisane bardzo niewiele:

Komunikacja odbywa się za pośrednictwem protokołu TCP.

Wiadomości wysyłane są w formacie JSON.

Jednak taka definicja protokołu pozostawia bardzo dużo do życzenia; nic nie wiadomo o tym, jak konkretnie należy enkodować wiadomości JSON w strumieniu bajtów TCP.

[BartoszChrostowski]

Jesteśmy otwarci co do propozycji dotyczące protokołu, nie zgłębialiśmy tego tematu.

UTF-8

[metiulekm]

UTF-8

Nie o to mi chodziło (ale moja wina, zapomniałem że słówko "encoding" ma konkretne znaczenie). Ale jeśli już o tym mowa, to IMO troszkę overkill, ASCII nie wystarczy?

Jesteśmy otwarci co do propozycji dotyczące protokołu, nie zgłębialiśmy tego tematu.

U nas chyba wyglądało to tak, że po prostu na strumieniu TCP wysyłaliśmy kolejne wiadomości oddzielone znakami nowej linii (przy czym każda OFC musiała się zmieścić w jednej linii). Jest to chyba mniej lub bardziej standardowy zapis strumienia wiadomości JSON. Trzeba by to było jakoś uściślić jeszcze, warto by było wprowadzić limit długości jednej wiadomości oraz rozważyć ponowne łączenie się (w szczególności, co się stanie jeśli ktoś spróbuje się połączyć, a połączenie tego ID już istnieje?).

Temat bezpieczeństwa zupełnie olewamy? (Nie obrażę się, jest to chyba troszkę out of scope).

[BartoszChrostowski]

UTF-8. Nie ma żadnej zalety użycia ASCII

U nas chyba wyglądało to tak, że po prostu na strumieniu TCP wysyłaliśmy kolejne wiadomości oddzielone znakami nowej linii (przy czym każda OFC musiała się zmieścić w jednej linii). Jest to chyba mniej lub bardziej standardowy zapis strumienia wiadomości JSON. Trzeba by to było jakoś uściślić jeszcze, warto by było

To jest duplikacja #55

Nie wiem jeszcze jak z ponownym łączeniem. Wolałbym kończyć działanie na zerwanie jakiegokolwiek, ale jeśli są jakieś przeciwskazania, których nie widzę, trzeba będzie dodać taką możliwość.

Temat bezpieczeństwa definitywnie olewamy, nie ma sesnu skoro to nie jest wymagane.