4. UDP-Server Nebenlaeufigkeit

UDP-Server Nebenlaeufigkeit

  • J

    Hallo Zusammen,

    Ich moechte eine UDP-Server schreiben die nicht inkrementell arbeitet(jede Anfrage
    nach dem anderen), sondern Nebenlaeufig(Concurrent).

    Dazu moechte ich bei dem Server nach "dem ersten recvfrom vom Client" einen neuen
    Prozess erstellen, der die weitere Datenuebertragung von dieser Client
    uebernimmt. Ist sowas bei Verbindungslosen-Sockets ueberhaupt moeglich? Wenn
    ja, wie muss ich vorangehen? Ich habe im Netz dazu diesen Thread gefunden was
    mir code-technisch nicht weitergeholfen hat:
    http://unix.derkeiler.com/Newsgroups/comp.unix.programmer/2004-01/0382.html

    Noch code zu meiner Erklaerung:

    int main(int argc, char** argv){

    int serv_fd ;
    struct sockaddr_in server ;
    struct sockaddr_in client ;
    socklen_t addr_len = sizeof(client) ;
    pid_t act_pid ;
    char buf[MAXLEN] ;

        if((serv_fd = socket(AF_INET, SOCK_DGRAM, 0) )== -1) /* udp so..*/
            return 1 ;

        server.sin_family = AF_INET ;
        server.sin_port = htons(9009);
        server.sin_addr.s_addr = "localhost" ;
        memset(server.sin_zero, '\0', sizeof(server.sin_zero)) ;

        if(bind(serv_fd, (struct sockaddr *) &server, sizeof(server))==-1 )
            return 1;

        /* hier soll fuer jeden neuen Client einen neuen Prozess erstellt werden. */

        while( recvfrom(serv_fd, buf, MAXLEN-1, 0, (struct sockaddr *)&client, &addr_len) != -1){

            act_pid = fork() ;

            if(act_pid == 0){
                /* behandle den datagram paketen (callback kommt) */

                exit(0);                /* we dont need child anymore */
            }
            else { }/* wait for the incoming clients */

        }
return 0 ;
}

    Danke im voraus,

    0
  • ?

    bei udp ist das nicht ganz so einfach und vom application level protokoll abhängig. grundsätzlich gilt, dass du für udp zwei strukturen an den neuen prozess geben musst: die absender daten und die daten, die beim server eingetroffen sind. mit den absender daten kann der neue prozess dann die antwortdaten an das richtige ziel schicken. hier ist aber die reihenfolge zu bedenken. schickt ein client vom gleichen port aus zwei udp pakete los, so muss es nicht sein, dass beide in der selben reihenfolge ankommen. weiters kann zb die anfrage für das zweite udp paket schneller im server bearbeitet worden sein als die erste. dadurch bekommst du vielleicht probleme bei der zuordnung der antwortpakete zu den anfragepaketen im client. das musst du bei udp im application level lösen. außerdem solltest du lieber threads und keine prozesse verwenden.

    0
  • J

    udp schrieb:

    grundsätzlich gilt, dass du für udp zwei strukturen an den neuen prozess geben musst: die absender daten und die daten, die beim server eingetroffen sind. mit den absender daten kann der neue prozess dann die antwortdaten an das richtige ziel schicken.

    Danke fuer die Antwort erst mal. Ich denke eine solche Portaenderung dem
    Client mitzuteilen, sollte der Server sich mit dem Client synchronzieren. Anders
    geht nicht:

    [c1] -----> [s p1]
     sendto   |      (fork,
              |       port aenderung)
[c1] <----- [s p2]    (c1 wartet blockiernd auf nachricht mit timeout -select) 
    sendto

[c1] <----> [s p2]

     -----> [s p1] (lauscht auf well-known port)

    Nach dem c1 sich bei server meldet, kann der server forken(prozess 2), und durch
    diesen Prozess eine leere nachricht mit richtigen Socketdaten zum Client wird
    geschickt(sync data wuerde ich das nennen). Und danach kommuniziert der klient
    nur mit dem Prozess weiter.
    http://jlbtc.eduunix.cn/index/html/unix/Addison Wesley - UNIX.Network.Programming.Volume.1.3rd.Ed.The.Sockets.Networking.API-LiB/0131411551_ch22lev1sec7.html

    udp schrieb:

    hier ist aber die reihenfolge zu bedenken. schickt ein client vom gleichen port aus zwei udp pakete los, so muss es nicht sein, dass beide in der selben reihenfolge ankommen. weiters kann zb die anfrage für das zweite udp paket schneller im server bearbeitet worden sein als die erste. dadurch bekommst du vielleicht probleme bei der zuordnung der antwortpakete zu den anfragepaketen im client.

    Ich kann dieses Problem umgehen, in dem ich am Anfang der Verbindung zwischen
    CLient und Server, nur ein Synchronizationsdata hin und her schicke? Das bedeutet,ein aber nur ein leere Packet mit Verbindungsinfo von Client zu Server,
    dann vom Server zu Client? Dann beim Client mit select wuerde ich versuchen
    einen Deadlock mit timeout zu verhindern.

    udp schrieb:

    außerdem solltest du lieber threads und keine prozesse verwenden.

    ja, spaeter, erst nach der erfolgreichen Umsetzung meiner Gedanke mit Prozessen 😉

    0
  • ?

    ich hab in deinem anderen thread schon auf die fragen von hier geantwortet, denk ich.

    0
Anmelden zum Antworten