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.