2

I have been using UDT library a udp based protocol for sending files and I notice that the send function sends the data to a buffer before returning in blocking mode. However the send function seems to return without sending the entire data in blocking mode(send() returns the amount of data sent). What could be the possible reason for this prob and what should be done to send the remaining data if the prob cannot be solved? I used winsock library for tcp and udp but i dont get this prob for tcp or udp send(similiar in functionality to udt). Tested all the programs by transferring same files & network. 

    int a;
    if (UDT::ERROR == (a = UDT::send(*(UDTSOCKET*)sock, buffer, size, 0)))
    {
        cout << "send: " << UDT::getlasterror().getErrorMessage() << endl;
        return -1;
    }
    else
    {
        return a;
    }
    This is the code i use. the value of 'a' is not the same as 'size' at times.

I know this can happen if its non-blocking but i am using blocking send with infinite timeout.

kishore
  • 604
  • 3
  • 7
  • 13

2 Answers2

2

If you have a send timeout set, this is probably a timeout. If not, you can consider this an error that is fatal to the connection. You can call getlasterror to find out what went wrong.

David Schwartz
  • 179,497
  • 17
  • 214
  • 278
  • Thanks for the answer. I have not set send timeout. I ll check with getlasterror and try to see what went wrong. – kishore Feb 22 '14 at 09:53
  • I tried using getlasterror() but that didnt return me anything. Encountering this problem only for udt, not for tcp and udp. Have no clue of how this is happening. should i change the buffer size or somethin? – kishore Feb 22 '14 at 10:45
  • 1
    What do you mean by "didnt return me anything"? Do you mean it returned SUCCESS (0)? You should just be able to call [send](http://udt.sourceforge.net/udt4/doc/send.htm) again to send more or get an error. – David Schwartz Feb 22 '14 at 11:02
  • 1
    I was actually thinking that blocking send meant that it will return only after sending all the data to the kernel buffer as it works in TCP. I later realized that it was the programmer's responsibility to send it again. Thanks for mentioning - "You should just be able to call send again to send more or get an error" I just required a small change to the existing send. Thanks for the hint! – kishore Mar 10 '14 at 13:57
-1

UDP datagrams are sent entire or not at all. The situation you describe is impossible. Please provide your evidence.

user207421
  • 305,947
  • 44
  • 307
  • 483
  • I don't think you understand his question. He's talking about UDT over UDP, not UDP. TCP packets are sent entirely or not at all too, but at the application level, you're not dealing with apckets. – David Schwartz Feb 22 '14 at 10:42
  • @DavidSchwartz He's talking about the send() function not sending a complete datagram as far as I can see. This does not happen. Let's see the evidence. – user207421 Feb 22 '14 at 10:49
  • No, he's not. He's talking about the send function not sending all the data he asked it to. He's not talking about datagrams at all. They're an implementation detail with UDT, just as they are with TCP. They're not visible at the application layer because UDT hides them, just as TCP does. – David Schwartz Feb 22 '14 at 11:00
  • @David You are right. The udt is built over udp to ensure reliability. It has two variants - stream and dgram and i am using the stream mode. The protocol works at the application layer and is responsible for delivery of packets. The user only sees the return values of send and recvs. – kishore Feb 22 '14 at 11:30