Nah its only dedicated for communication up to 3 meters( i want to smoothly edit scene on different devices - this is just something like multiscreen purpose - theyll be working like one app - imagine that you have 4 phones, you have side projection, front projecrion, top projection and 3d projection and you model one object with them). And what about that commenting out the communication? You mean sending and receiving ? Well that is obvious i dont get any lag.

2 hours ago, _WeirdCat_ said:

But will tcp be able to handle this realtime chat? I doubt.

Outside of very specific scenarios involving packet loss, TCP is not particularly slow. If the data you are transmitting needs to be ordered (and/or lossless), it's going to take a fair amount of effort to design and build a UDP system that outperforms TCP in the general case.

11 hours ago, _WeirdCat_ said:

Thats exactly what im doing at this point. But will tcp be able to handle this realtime chat? I doubt.

Well, unless the link layer is relying on a human morse code operator, TCP should be able to handle the kind of data throughput you're playing with without blinking.

TCP over IP over 802.11n is about 150 megabits per second, divided by the number of devices on your AP.  That means you can send on the order of megabytes every second using TCP.  If you're experiencing delays on the order of seconds to send 20 bytes, the problem is not the underlying network protocol.  Switching to UDP will not alter that fact.

Setting TCP_NODELAY on the TCP channel means the driver won't wait for a full packet to send, which if you're streaming 20 bytes is what you want otherwise you will get, like the name says, delay.

You may want to dump timestamps of operations into a log file and analyse them.  It sounds more like you have inadvertent serialization in your multi-threaded application.  Also, make sure your sockets are read and written in O_NONBLOCK mode.  Your server should be waiting for events and dispatching them to worker threads and never waiting for read or write completion.  You should hold locks only as long as it takes to push or pull data from a queue (and the "data" should be about the size of a pointer or index).

Sequence diagrams are an indispensible tool for analysing flow in this situation. You can even annotate them with expected timings and then match against the actual timings from your log file.

Certainly, blindly fumbling in the dark by switching session protocols on the network is unlikely to get you to where you want to be.

Anyway despite post above, can someone explain to me why write fails on nonblocking socket set by fcntl() func

I get errno 32 which means EPIPE

Do i have to do maybe some additional things rather than just use write?

Code looks like that

const int max_write_fails = 18;


inline int SendStrToFd(unsigned char * pdata, int cmdlen, int sockfd)
{
	bool sentall = false;

	int count = 0;
	int iteration = 0;
	int fails = 0;
	int len_to_write = cmdlen;
	while (!sentall)
	{
		iteration++;
		if (count >= cmdlen) break;
		if (iteration > 1500) break;
		if (len_to_write <= 0) break; //we shouldnt even be here but ill add log exception
		int wb = write(sockfd, &pdata[ count ], size_t( len_to_write ));
		if (wb < 0) 
		{
			fails = fails + 1;
			if (fails >= max_write_fails)
		break;
		}
		if (wb >= 0)
		{
		count = count + wb;
		len_to_write = len_to_write - wb;
		}
		if (count >= cmdlen) { sentall = true; break; }
	}
	if ( sentall ) return 1; else return -1;
}

inline int SendStrToFd(AnsiString txt, int sockfd)
{
	int cmdlen = TextLength( txt );
unsigned char * pdata = new unsigned char[ cmdlen ];
for (int i=0; i < cmdlen; i++)
pdata[i] = ( unsigned char )txt[i];

int result = SendStrToFd(pdata, cmdlen, sockfd);
if (result < 0) ALOG("send error: "+errno2str());
delete [] pdata;
return result;
}

I just keep getting -1 on first write and so on

1 hour ago, _WeirdCat_ said:

I get errno 32 which means EPIPE

EPIPE typically means that the other end closed the connection. Are you sure both ends of this equation are working correctly?