dorkbox/udt

UDP-based Data Transfer Protocol

udt's Issues

mismatched delete fix

change line 202 of core.cpp from
delete m_pPeerAddr;
to
(AF_INET == m_iIPversion) ? delete (sockaddr_in*)m_pPeerAddr : delete (sockaddr_in6*)m_pPeerAddr;

connection broken error

on windows client I get connection broken after calling recvmsg after 3 to 4 minutes

Modified congestion control does not work

I extend the default congestion control as follows:
public class Test extends CCC{
public Test(){
System.out.println("I am here!");
}
public void setCwnd(int win){
setCWndSize(win);
}
}

I set the customized CC for the SocketUDT instance as follows:
SocketUDT socket = new SocketUDT(TypeUDT.STREAM);
socket.setOption(OptionUDT.UDT_CC, new FactoryUDT(PCC.class));
socket.connect(new InetSocketAddress("127.0.0.1", 5555));
Object obj = socket.getOption(OptionUDT.UDT_CC);
Test test = (Test) obj;
test.setCwnd(1200);

The point is after this instant the congestion window remains fixed at 1200. I transfer huge files but the window does not change. The expected behavior here is that the default congestion control works as usual as I have not overridden any of the superclass methods. Let me know if this is a bug or I am getting something wrong here. Thank you.

DTLS Support

Is there a way to however use the UDT library in combination with DTLS ?

timeouts not working as expected in datagram mode

OK; we've been using UDTv4 implementation for quite some time now, still to our surprise we ran into some issues when trying to tweak the performance. We've been using UDT in data-gram mode.

To our surprise, the recvmsg function waits for the entire period of UDT_RCVTIMEO even if there are tons of messages already in the buffer.. is it by design? It's very easy to reproduce (..) just set timeout to say 15000 ms (..) send a few messages 40 bytes each (..) and see the socket blocking for minutes.

That results in extremely undesired scenarios (..) we've been seeing the receiving socket seemingly 'receiving' data long long after... the sending node... went offline. As perceived by the upper layers of the software. I mean come on, the variable is called a timeout.. not a polling time or whatever.

So if we set UDT_RCVTIMEO to a small value say 100ms .. is it just the polling time for results and would big messages be retrieved in any case? or is it the time after an entire datagram was not retrieved then the function returns an error?

typo in udtCommon.h

Looks like typo

UDT/src/udtCommon.h

Line 180 in b78bf81

pthread_cond_t m_TickCond;

mb it is supposed to use udt_pthread_cond_t instead of pthread_cond_t