Regarding tcpserver/tcpclient these don't cut it as they only forward numerical info. We need alphanumeric-compatible system like netsend/netreceive that also supports broadcasting.

We implemented disis versions of netsend/receive that combine netsend and udpsend into one (thus allowing broadcasting udp packets while also allowing text and numbers). I'll be releasing code for these and other externals as soon as I get a chance to clean them up for distribution.

These however still don't cut it (or to be more precise are kludge to use) when having multiple clients. This is where in theory netclient/netserver should shine, except for the aforesaid issues.

I've thought of however a way of significantly lowering broadcast's overhead as currently we broadcast cues for all musicians to all clients, rather than parsing them out (which is something that netserver conveniently includes). So, this may hopefully also cut down on the amount of data being sent.

Come to think of it, perhaps having to broadcast the same thing to multiple clients still fills up the same buffer causing problems? Is this indeed so? (e.g. sending a same text to 27 different clients, does that effectively multiply its size 27 times within the context of 4096 limitations).

Finally, it appears that netserver and netclient have arbitrarily assigned 4096 limitations with a DEFINE inside their source. I am wondering is this because of TCP's architecture (I thought I heard somewhere it could do up to 65535 per packet) or is this something we could simply change and recompile and thus achieve much better results?

Please advise.

Best wishes,

Ico