Socket Error probleem

[Griffin2k]

heb hiero een probleempje.. Hieronder de code... (Layout-verneukertje)

Maar het wordt gebruikt in een chat-applicatie in Visual C++...
Het probleem is dus dat de code altijd een socket-error genereerd zoals onderin de code staat..

Kan iemand mij misschien helpen hiermee? Doe ik iets fout?

code:

DWORD WINAPI atlmgrSocketListenThread(LPVOID lpParam)
{
    ATLMgr      *pMgr = (ATLMgr *)lpParam;
    SOCKADDR_IN siClient;
    char        szBuffer[256];
    int         iLen, iRet;
    
    // Continue eternally
    for ( ;; )
    {
        // Wait for data from the client
        memset(szBuffer, 0, sizeof(szBuffer));
        iRet = recvfrom(pMgr->m_iListenSocket,      // Bound socket
                    szBuffer,               // Receive buffer
                    sizeof(szBuffer),       // Size of buffer in bytes
                    0,                      // Flags
                    (LPSOCKADDR)&siClient,  // Buffer to receive client address
                    &iLen);                 // Length of client address buffer
        
        // Check if connection has been closed
        if (iRet == 0)
            break;
        
        if (iRet != SOCKET_ERROR)
        {
            // Show that we've received some data
            char szTmp[256];
            sprintf(szTmp, "ATLMgr::SetupPortListener: Data received: %s", szBuffer);
            g_Output.OutputData(szTmp);
            
            
            // TODO: Determine which stream should receive this data
            //       For now we'll just pass it to all streams
            
            for (ConnList::iterator i = pMgr->m_Connections.begin(); i != pMgr->m_Connections.end(); ++i)
                i->pCallback((unsigned char *)szBuffer, strlen(szBuffer));
        }
        else
        {
            char szTmp[512], szErr[256];
            FormatMessage(FORMAT_MESSAGE_FROM_SYSTEM, NULL, WSAGetLastError(), 0, szErr, 256, NULL);
            sprintf(szTmp, "ATLMgr::SetupPortListener: Socket error: %s", szErr);
            g_Output.OutputData(szTmp);
            break;
        }
    }
    
    // Return success
    return 0;
}

[SWfreak]

Welke error geeft ie dan precies? en wat is je code om een naar eens socket te luisteren? (recvfrom, je listen-loop). lijkt me dat daar eerder de fout zit dan hier....

[Griffin2k]

De error die hij output is: Het systeem heeft een ongeldig pointeradres gevonden

De luisterloop staat bovenin de code.. ook de recvfrom...

[riezebosch]

misschien beetje overbodig: maar volgens mij floep je na de eerste keer alweer je "oneindige" loop uit... Als het fout gaat doe je namelijk een break, en als het goed gaat een return.

[Griffin2k]

Als het fout gaat dan wil ik juist dat die thread afgelopen is.. dus met een break.. als het goed gaat dan een return want dan blijft de thread lopen!

Dat zal niet zozeer het probleem zijn... hij heeft een ongeldig pointeradres gevonden.. dus een nullpointer denk ik... maar het probleem is dus waarvandaan..

Ik dnek zelf uit dit stukje, maar kan de fout niet ontdekken:

code:

// Wait for data from the client
        
memset(szBuffer, 0, sizeof(szBuffer));
iRet = recvfrom(pMgr->m_iListenSocket,      // Bound socket
                        szBuffer,           // Receive buffer
            sizeof(szBuffer),       // Size of buffer in bytes
            0,              // Flags
            (LPSOCKADDR)&siClient,                  // Buffer to receive client address
            &iLen);                     // Length of client address buffer

[LAN]

'Als' het in dat stukje code zit, dan zou het die "pMgr->m_iListenSocket" moeten zijn, voor de rest is je recvfrom() goed.

Misschien zou je je iLen nog zo moeten initialiseren:

code:

iLen=sizeof(struct sockaddr);

Dit is wat generic code, zal ook wel voor Winsock werken.

[ Voor 47% gewijzigd door LAN op 03-04-2003 13:29 ]

[Griffin2k]

LAN, IK HOU VAN JE!!!!!!!!!!!!!!

Ahumm... sorry whaha.... Hij werkt

Dankjewel...

[LAN]

Wow (: rustig aan.
Was het nou die initialisatie? Ik verwacht het haast van wel.


Als ik het zo zie dan gebruik je UDP, vanwege die recvfrom().
Maar... dat zegt helemaal niets, recvfrom kun je ook bij TCP gebruiken.

Mocht je nou wel TCP gebruiken (verstandig voor een chat omgeving), dan kun je misschien recv() nemen, werkt ietsje makkelijker.

[ Voor 70% gewijzigd door LAN op 03-04-2003 14:01 ]

[Griffin2k]

Ja het was die initialisatie! en ja ik gebruik UDP ja!

Zou TCP wat makkelijker / beter zijn dan? want das een klein verschil in mijn code...

[LAN]

Als je UDP gebruikt zou iemand pakketten kunnen sturen naar je chat server met onjuiste gegevens (ander ip source adres bijvoorbeeld).
TCP maakt dit vrijwel onmogelijk. Het levert wel wat extra programmeerwerk op.

Moet je maar even kijken in hoeverre dit een belangrijk project is.

[curry684]

LAN schreef op 03 April 2003 @ 14:09:
Als je UDP gebruikt zou iemand pakketten kunnen sturen naar je chat server met onjuiste gegevens (ander ip source adres bijvoorbeeld).
TCP maakt dit vrijwel onmogelijk. Het levert wel wat extra programmeerwerk op.

Moet je maar even kijken in hoeverre dit een belangrijk project is.

Met TCP kun je net zo hard de afzender faken als met UDP, en bij allebei is het net zo nutteloos naar een chat-applicatie (je krijgt nl. de responses dan niet terug).

Tevens levert TCP niet of nauwelijks meer programmeerwerk op (je moet een vlaggetje omzetten), meestal juist minder! Clue is dat TCP een Controller protocol is met ingebouwde sequencing, acking en checksumming, 3 dingen die UDP niet native heeft. De eerste zorgt ervoor dat je de pakketjes in dezelfde volgorde binnenkrijgt als dat ze verstuurd zijn, de 2e zorgt ervoor dat alle pakketjes opnieuw verstuurd worden als ze niet binnen x tijd ontvangen zijn, en de 3e zorgt ervoor dat je data niet kan corrupten onderweg. Het gebrek aan sequencing zorgt er tevens voor dat een UDP pakket max. 480 bytes mag zijn terwijl je over TCP kunt streamen wat je maar wilt.

Het grote beslissingspunt is de netwerk- en CPU-loads. UDP is lightweight fire-and-forget werk, en om die reden wordt het gebruikt voor vaak uitgevoerde tasks met weinig data (DNS werkt normaliter via UDP). TCP is voor datahongerige applicaties met dikke(re) CPU's.

Ter vergelijking: MSN Messenger heeft een enorm ultra-phat TCP protocol. ICQ werkt via UDP (vandaar in oudere versies de messagelimiet van ~400 bytes). ICQ deed echter altijd al uitgebreid zelf voor acking, sequencing en checksumming zorgen, beetje overbodig dus.