Niestety, gdy po jakimś czasie się połączę, dostaję ogromną ilość starych danych.
Bo pierwszy netcat pisze na swój stdout, a w momencie kiedy podłączysz się drugim, dostaje on ten stdout.
Nie zrobisz tego co chcesz w taki sposób. "Buforowanie" które wyłaczyłeś działa w zupełnie inny sposób (dane nie są zatrzymywane, tylko wysyłane od razu - ale to kompletnie nie odnosi się do tego przypadku).
Sugeruję rozwiązać to po ludzku, czyli socketami - serwer nasłuchuje na jakimś porcie, i w momencie kiedy się podłączy klient zaczyna wysyłać do niego wiadomości - a jeśli żaden klient nie jest podłączony, nie wysyła żadnych wiadomości.
A czy ta twoja funkcje measure na pewno jest blokująca? Czy ona po prostu zmienia wartość z częstotliwością 1kHz? Bo jeśli ona nie blokuje to generujesz pakiety non stop i zwczajnie system nie wyrabia z ich wysyłaniem.
To nie to, po prostu łączy się do serwera który wysyła mu całe historyczne dane
Poza tym TCP w tym przypadku nie jest chyba najlepszym pomysłem, bo ma wbudowane mechanizmy opóźniające jeśli klient nie umie odbierać odpowiednio szybko no i retransmisje mogą cię tu blokować dodatkowo. Wydaje mi sie że UDP w tej sytuacji byłoby sensowniejsze.
Nie dawaj ludziom takich pomysłów, bo później słuchają. Poza - czasami - gamedevem i innymi rzeczami realtime nie widziałem jeszcze własnego protokołu opartego na UDP (stworzonego przez zwykłą firmę, a nie trzy komitety i dwie korporacje) gdzie użycie UDP było uzasadnione.