[Lewo]

Mirki chciałem sobie zaimplementować serwis do gry w szachy.
Zastanawiam się jaki protokół wykorzystać do przesyłania ruchów.

Gracz wysyła ruch na serwer -> Serwer sprawdza poprawność ruchu -> Serwer wysyła nową pozycję do obu graczy w grze
Wysyłanie co ruch żądania POST wydaje mi się zasobożerne i wolne.

Myślę, że powinienem wykorzystać
REST api (http) - do tworzenia gry, konta itd
Socket (tcp) - serwer dla gry ma osobny wątek który trzyma: socket per gracz i jest pośrednikiem (tj. gracza A robi ruch -> serwer waliduje -> wysyła do obu graczy nową pozycję)

Trochę mnie dziwi, bo lichess.org ma API do wykonania posunięcia
https://lichess.org/api#operation/boardGameMove
ale jak gram przez web, to nie widzę w konsoli by szły żądania POST posunięć

Jak to ugryźć bo nie mam doświadczenia? Programować będę w Javie jak to ma jakiś wpływ.
Ewentualnie możecie polecić jakąś bibliotekę do komunikacji sieciowej, jeśli sam Socket javowy jest zbyt niskopoziomowy, bo w Springu pewnie zrobię tylko REST Api

#java #naukaprogramowania #programowanie #szachy

[sokytsinolop]

@Lewo: websockets

[sokytsinolop]

@Lewo: i btw lichess jest opensource wiec mozesz sie pobawic https://github.com/ornicar/lila/

[Lewo]

@sokytsinolop: obczaję :)
https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_a_WebSocket_server_in_Java
https://spring.io/guides/gs/messaging-stomp-websocket/

a tak tldr - czym web socket różni się od socketa zwykłego? bo to też chyba działa na tcp.
czy to jest po prostu socket, a websocket to nazwa na API który socket oferuje i przystosowany jest do czegoś?

[sokytsinolop]

@Lewo: nie wiem ale jak sie dowiesz to mozesz mi napisac jak to wyglada - chetnie sie dowiem

[bambadjan]

@Lewo: dopóki nie piszesz aplikacji w której spodziewasz się równolegle setek tysięcy graczy to REST jest ok. Napisz wszystko tak, żeby w miarę łatwo móc podmienić protokół i sobie sprawdzisz jak działa jedno i drugie, tak czy inaczej chcesz się nauczyć.

[cochese]

Wysyłanie co ruch żądania POST wydaje mi się zasobożerne i wolne.

@Lewo: To będzie blitz chess na światowym poziomie ( ͡° ͜ʖ ͡°) ? Jeżeli nie, to POST nie będzie za wolny.

[Lewo]

@bambadjan: w sumie chciałbym to napisać z ciekawości tak jak powinno to być w komercyjnym projekcie.

Zastanawiam się tylko czy jak przerzucę się z rest http na coś innego to strasznie utrudni to pisanie kodu czy też nie.

[Lewo]

@cochese: okej. dlatego właśnie też mi się wydaje, że te api na lcihess dostępne jest jakby ktoś chciał swojego klienta napisać. ale ich domyslny dziala jakoś inaczej bo nie widzę żądań. Chyba, że te żądania "http" są wysyłane jako body treści przez socketa :D

[Lewo]

@bambadjan: jak dobrze odizoluje pojedynczą gre to będzie kwestia zmienienia proxy. Tylko z moim juniorskim doświadczeniem zrobię jakiś powiązany syf :D no to zobaczymy :) Najwyżej dla zabawy czat w grze napiszę w websocketach dla sprawdzenia się.

[Krucyfiks]

@Lewo:

Zastanawiam się tylko czy jak przerzucę się z rest http na coś innego to strasznie utrudni to pisanie kodu czy też nie.

Jeśli logikę wyrzucisz po za kontrolery i fajnie porozdzielasz serwisy, to w teorii http to tylko medium transportowe, które zamieniając na ws nie powinno zabrac duzo czasu

[cochese]

@Lewo: Dobra ziom, doczytałem całego twojego oryginalnego posta. Skupmy się na tym fragmencie:

gracz A robi ruch -> serwer waliduje -> wysyła do obu graczy nową pozycję

Otóż POST, jak każda inna metoda HTTP działa w schemacie "żądanie -> odpowiedź", przy czym to klient HTTP wysyła żądanie do serwera, a serwer odpowiada. Serwer nie może ani wysłać żądania do klienta, ani odpowiedzieć, jeżeli klient nie wyśle żądania. Biorąc to pod uwagę

[Lewo]

a wcześniejsza odpowiedź o tym, że "POST nie będzie za wolny" była błędna, bo połowiczn

@cochese: dzięki, chociaż akurat chciałem przedstawić schemat komunikacji jaki widzę, że jest potrzebny (bez sugerowania, że to da się zrobić w http).

Masz rację, dlatego właśnie pisałem też coś o tym, że sama pojedyncza gra powinna być wątkiem serwera, który trzyma dwa połączenia per gracz i może tak się z nimi komunikować.

Jeśli chodzi o HTTP

[Lewo]

@cochese:
z ciekawości zrobiłem dzisiaj reseach o WebSocketach i takie coś znalazłem w Springu docsach

The best fit for WebSocket is in web applications where the client and server need to exchange events at high frequency and with low latency

Even in cases where latency is crucial, if the volume of messages is relatively low (e.g. monitoring network failures) the use of long polling should be considered as a relatively simple

[Lewo]

jeszcze ciekawy obrazkowy przegląd technik otrzymywania update-ów od serwera
https://stackoverflow.com/a/12855533

[sokytsinolop]

@Lewo: dzieki <3