发送/接收套接字阻止问题

Question

another question about my beloved sockets. I'll first explain what my case is. After that I will tell you whats bothering me.

I have a client and a server. Both Applications are written in C++ with the winsock2 implementation. The connection runs over TCP and WLAN. WLan is very important, because its probably causing the issue and is definetly going to be the communicationchannel.

I'm connecting two sockets to the server. A SendSocket and a ReceiveSocket. I'm constantly sending video data to the server through the sendsocket. The data is processed and gets send back to the client and gets displayed. Each socket got his own thread.

The Videodata is encoded, so I achieve like 500kB/s. Lets see this rate as fixed, without explanation.

Perfect communication viewed by the client:

Send Data
Recv Data
Send Data
Recv Data
...

This is for like 100 frames the case.

But every couple of frames, the stream freezes for like 4 frames and continues after that. (4 frames are like 500ms)

Thats the issue, i'm facing.

What happens to the stream is the following:

Send Data
Recv Data
Send Data
Send Data
Send Data1 -> blocked send
Recv Data
Recv Data
Send Data2 -> not blocked anymore.

The Data gets properly sent on server side.

Since WLan is not duplex (as far as I know), I thought, that the send calls are prioritized for some reason. And after that the Receive calls are prioritized, so the send call blocks until the recv calls are done.

Maybe you can tell me, what is happening in the lower layer, which could cause the problem. Btw. I'm definetly not sure, if its not just a bandwidth issue, but I thought WLAN should be able to handle 500kB/s. This 500kB/s are both upstream and downstream together. Important notice: If I set the framerate to a factor of 1/5, it does not fix the issue.

I know it's hard to fix this issue with this insight. I would be happy, if you could share your knowledge, so I may be able to fix it myself.

EDIT: Its perfectly fine, if the client recv hangs a litte. But it must not block the send. The server needs data continuosly.

Answer 1

A blocked send means either that the socket send buffer is full, which means either (a) that the socket receiver buffer at the receiver is full, which means the receiver isn't reading as fast as you're sending; or else (b) that there are network losses that are causing the sender to retry. In either case there is nothing you can do about it at the sending end.

Someone is bound to mention non-blocking I/O as a solution, but it isn't: at the point where a blocking sender blocks, a non-blocking sender will get -1 from send() witch 'errno == EAGAIN/EWOULDBLOCK', which doesn't solve the actual problem at all.

Answer 2

Alright then. It was definetly a wlan issue. I tested over the eduroam wlan at my university. I don't know, if anybody knows it. Now I tested it with a simple router and it worked fine. Seems like the eduroam wlan does have some trouble with bandwidth or direction changes. I won't look into that...