I need that when I call send(), my application does not reach the next line until that send is completed. I've been doing it by calling select(), but is there any other way to do it?
I need that when I call send(), my application does not reach the next line until that send is completed. I've been doing it by calling select(), but is there any other way to do it?
use asynchronous or non-blocking sockets
http://tangentsoft.net/wskfaq/articl...trategies.html
I think this would go in the "Networking/Device Communication" section
Last edited by h_howee; 06-15-2007 at 11:59 AM.
OS: Windows 7, XUbuntu 11.10, Arch Linux
IDE: CodeBlocks
Compiler: GCC
Nono, I WANT to block... I want blocking sockets... But the recv() is the only one that is actualling blocking, send() is not.
Why would you want that?
if you want blocking sockets, don't use selectI've been doing it by calling select(), but is there any other way to do it?
when recv blocks, its usually waiting for data but what is there for send to do? it just sends the data out and returns
were you unable to send all the data at once? if so...
http://beej.us/guide/bgnet/output/ht...t.html#sendall
OS: Windows 7, XUbuntu 11.10, Arch Linux
IDE: CodeBlocks
Compiler: GCC
I just need the application that calls send() to stop until the recv() receives all the data, for different reasons...
Make the application that calls send() call recv() directly afterwards and wait for the application that calls recv() to send a confirmation using send().
There's no other way.
Well, there might be other ways, but they will typically be more complex.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
There is no other way. send() will not reliably block, it isnt supposed to. I suppose you could hack the berkely sockets code under linux to make the TCP/IP protocol implement some sort of blocking sequence, but then it would just be the same as having a recv() after the send to wait for a confirmation and might break the protocol, or at least make it under-perform.
perhaps if you shared the reasons we might be able ot give you a more specific solution.Originally Posted by manugarciac
