Menu

bugs in non-blocking connect

SAPikachu
2011-06-01
2014-04-28
  • SAPikachu

    SAPikachu - 2011-06-01

    Hi,

    I just tested the latest version. Seems non-blocking connect works, thanks for your efforts to implement it! I have found some bugs though:

    1) After connection, it is immediately signaled as readable in epoll, regardless whether the read buffer has data.

    2) If I break at the beginning of int CUDT::connect(const CPacket& response), wait for a few seconds and then resume, the program will crash at:

    void CUDTUnited::checkBrokenSockets()
    {
       CGuard cg(m_ControlLock);
       // set of sockets To Be Closed and To Be Removed
       vector<UDTSOCKET> tbc;
       vector<UDTSOCKET> tbr;
       for (map<UDTSOCKET, CUDTSocket*>::iterator i = m_Sockets.begin(); i != m_Sockets.end(); ++ i)
       {
          // check broken connection
          if (i->second->m_pUDT->m_bBroken)
          {
             if (i->second->m_Status == LISTENING)
             {
                // for a listening socket, it should wait an extra 3 seconds in case a client is connecting
                if (CTimer::getTime() - i->second->m_TimeStamp < 3000000)
                   continue;
             }
             else if ((i->second->m_pUDT->m_pRcvBuffer->getRcvDataSize() > 0) && (i->second->m_pUDT->m_iBrokenCounter -- > 0)) // crash at this line
             {
                // if there is still data in the receiver buffer, wait longer
                continue;
             }
    // snip
    

    3) The socket status is changed to CONNECTED immediately after calling connect. (Is this intentional?)

     
  • SAPikachu

    SAPikachu - 2011-06-02

    More tests shows that the #2 bug is always triggered on connect time out.

     
  • Yunhong Gu

    Yunhong Gu - 2011-06-03

    Thanks, fixed the first bug (simple). Verified the 2nd/3rd bug (the 3rd one caused the 2nd one). Will fix soon.

     
  • SAPikachu

    SAPikachu - 2011-06-03

    Got it, thanks. :)

     
  • SAPikachu

    SAPikachu - 2011-06-03

    Just found another bug, sometimes it will crash at the beginning of void CSndUList::remove_(const CUDT* u). Maybe they are related.

     
  • Yunhong Gu

    Yunhong Gu - 2011-06-06

    new fix submitted. Hopefully this will fix all the 3 problems.

     
  • SAPikachu

    SAPikachu - 2011-06-06

    Thanks, I will test it later.

     
  • SAPikachu

    SAPikachu - 2011-06-07

    Just tested the new version, problems in OP are fixed, but it still randomly crash CSndUList::remove_. Memory analysis shows that object in address u is overwritten. I suspect it is already released.

     
  • xorg

    xorg - 2014-04-28

    hi,

    trying to use non-blocking connect, which is supposed to be working, but not really documented. for example, after starting connnect, it is not clear how to find out whether connect succeeded, failed, or timed out. could you maybe post some example code that uses non-blocking connect?

    thank you in advance!

     

Log in to post a comment.