1. closing this somewhat unnecessary thread:

tcp(socket)server seemingly ignoring some tcpclient appears to be a

tcpclient_send_byte: could not send data

tcpclient gives this console message only once, in my case it got drowned in all the prints i did (for debugging (sic)). due to in-experience with the net objects the patch did not pay
attention to a possible 'blocked' message of tcpclient.

2. tcpserver establishes 2 connections/sockets for the same tcpclient

when the tcpserver starts after the tcpclient is already in the air.

Pd-console of server:

tcpserver listening on port 3000 tcpserver: accepted connection from 192.168.3.105 on socket 1188 tcpserver: accepted connection from 192.168.3.105 on socket 1156

Pd-console of client:

:: disconnect 52 16 tcpclient: not connected tcpclient: connecting socket 988 to port 3000 :: up 52 19 :: up 52 20

the :: lines are [print]s i make with time in min & secs; the ::up
lines are triggered by the 3rd outlet of the tcpclient which signals
about connected or not.

in my case it's not causing problems, but it's confusing and also a
bit strange because tcpserver is supposed to check whether a
connection is already in play, like it does when given a second
[connect ..( message.

3. with pd.com chasing ghosts?

also because the client patch sometimes crashes for unclear reasons, i
started using the command line "pd.com -stderr -open tcpclient-patch". it caused me quite some headaches.

first it gave an disturbing error message:

tcpclient: not connected tcpclient: connecting socket 600 to port 3000 tcpclient: connecting stream socket: Unknown error (10060)

secondly ALL the clients got blocked very quickly:

tcpclient: send: No error (0) tcpclient_send_byte: could not send data

it led me to an unproductive query for information about these
appearances, until the lucky idea to use pd.exe instead. then i was back at the situation with only once in a while a send blocked.

is this to be expected using pd.com? or is it specific for tcpclient?

rolf