Cześć,
Piszę prosty komunikator sieciowy i mam w 80% zrobione GUI, przymierzam się do napisania Client.java oraz Server.java.
Czy znalazł by się tutaj ktoś, kto pomógł by spiąć GUI z tymi klasami?
Niby wiem jak to napisać, ale nie do końca wiem czy dobrze rozumiem, co w jednej klasie zrobić jako publiczne, żeby wiadomość doszła od A do B ;)
Po jakim protokole będzie się komunikował klient z serwerem?
początkowo chciałem zrobić po TCP - jeden serwer, wiele klientów, ale teraz doczytałem, że ma to być P2P, ale oczywiście aplikacja będzie odpalona na 2 komputerach połączonych ze sobą kablem sieciowym ;)
Hmmm
do P2P będzie taka sama zasada działania?
paffelec napisał(a):
początkowo chciałem zrobić po TCP - jeden serwer, wiele klientów, ale teraz doczytałem, że ma to być P2P, ale oczywiście aplikacja będzie odpalona na 2 komputerach połączonych ze sobą kablem sieciowym ;)
Oj panie. Książkę otwórz i doczytaj :(.
TCP to protokół warstwy transportowej. Tak samo jak UDP, SCTP czy DCCP.
P2P to model komunikacja pomiędzy agentami w systemie. Tak samo jak klient-serwer.
To co musisz zrobić, to zdefiniować protokół aplikacji, który wyznaczy Ci granice wiadomości (PDU: https://en.wikipedia.org/wiki/Protocol_data_unit). TCP jest protokołem strumieniowym, wiec nie wyznacza granicy pomiędzy wiadomościami z wyższej warstwy. Aplikacja sama musi znaleźć te granice w strumieniu bajtów i dokonać deserializacji wiadomości, ewentualnie poczekać na brakująca część strumienia. Ponieważ to jest chat, to najprościej w takim wypadku założyć, że granicą jest koniec linii (albo dwa końce z powrotem karety \r\n\r\n , niektóre protokoły z tego korzystają, np SMTP czy HTTP). Inna opcja to skorzystać z biblioteki do serializacji, jak protobuf, thrift lub ręcznie zakodować wiadomości jako uproszczone TLV (https://en.wikipedia.org/wiki/Type-length-value, jako minimum potrzebujesz liczby bajtów w wiadomości i samej zawartości wiadomości).
Jeszcze proście jest zrezygnować z TCP na rzecz UDP, które gwarantuje zachowanie granicy wiadomości, kosztem niezawodności dostarczenia oraz limitem ~64kb długości wiadomości. Wtedy każdy datagram, który zostanie przeczytany jest pełną wiadomością.
Jeżeli jesteś leniuchem, to zamiast wyszukiwać granicy wiadomości w strumieniu możesz założyć, że każda wiadomość tworzy nowe połączenie TCP. Osobiście nie polecam, bardzo szybko można wyczerpać liczbę portów efemerycznych a i wydajność będzie słaba.
Jeżeli nie musisz operować bezpośrednio na sockecie, to możesz zaimplementować prosty serwer HTTP albo RPC.