Sockets buffer?

it may be buffered, if thats the case. look for a flush function, or better yet: read from the socket.

a read after a write is almost always guaranteed to flush all write buffers.

TCP buffers with the Nagle algorithm, which tries to group as many packets together to send as it can, so that the header overhead is as small as possible, and bandwidth is maximized.

Don''t be a dumbass and disable Nagle either.

It shouldn''t matter how its buffered, just do your send and move on with it. As the above poster mentioned, a recv() will usually make it send right away.

I tryied to read from the socket but it allways return WSAEWOULDBLOCK. :/ Any ide why? And I can´t find anyway to flush the buffer.

[edited by - zoot on October 20, 2003 4:36:29 AM]

Zoot, check my response to your other post in the Multiplayer section. The reason you get that error is because no data is available to read. You need to give the networking system time to successfully send the data. In non-blocking mode, you don''t explicitly wait until its available, so you need to keep waiting and checking using your program logic until it eventually gets transfered.

quote:

---

Original post by jermz
Zoot, check my response to your other post in the Multiplayer section. The reason you get that error is because no data is available to read. You need to give the networking system time to successfully send the data. In non-blocking mode, you don''t explicitly wait until its available, so you need to keep waiting and checking using your program logic until it eventually gets transfered.

---

Read the question, it is not the same. I am not trying to read anything at all. And isn´t 10 sec long enough to send 10 byte? Btw is it possible to detect when all data is sent(nonblocking)?

Zoot, the implementation of TCP is far more complex then "ok heres the data, now send it". If you want that, you should go with UDP.

TCP offers a stream based dependable solution(you dont send packets, you send individual bytes) at the expense of a complicated inner working. This is established by some ACK/NACK and buffering process that is transparent to the C/C++ coder.

Depending on the implementation if no data is being asked for from the sender, the sender may not send anything. This is what others are suggesting to you: When you create your server to send data, also write a simple client that asks for data from server.

You can also try sending a relatively bigger buffer.

Oztan

It shouldn''t matter when the data is sent. It will get sent, I don''t see a reason as to why it matters when. Such is the nature of TCP. If you have time-sensitive data then use UDP.

Whichever I/O strategy you choose for networking, you''re pretty much stuck to. Read up on them, there are about five under Windows:
* blocking
* nonblocking
* asynchronous
* overlapped
* I/O completion queues

That''s relative order of difficulty I think. There may be others I can''t remember.

quote:

---

Original post by Zoot
[Snip]
Btw is it possible to detect when all data is sent(nonblocking)?

---

Theres an easy way - take out the call to Sleep(). The data will be copied into the socket layer before the function returns, so you don''t need to worry about the data going out of scope before its sent or anything. The point in nonblocking sockets is that you just call send(), and the socket layer delivers it in packets to its destination.
You can tell if the socket buffer is full, since send() will give you the error WSAEWOULDBLOCK.

Why do you need to know when the datas been sent anyway? You won''t be able to tell when its received by the client, only when its left the socket layer.

I agree that when using TCP, you generally just care that the data gets there, and not when. But 10 seconds is an outrageous amount of time, and I can''t imagine you can chalk that up to normal TCP delays. I believe the Nagle and ACK delays could add up to somewhere around 1/2 sec or so.

I''m curious how you are checking this timing, and that its consistent. I don''t believe there is any way to determine when the data has phsically been sent. Is the receiving end constantly reading the data? If not, the send could be waiting for the recv buffer to un-fill. Just an idea.