4. Verständnisprobleme mit pthread/Sockets

Verständnisprobleme mit pthread/Sockets

  • S

    Hallo erstmal
    Ich hab folgendes Problem.
    Ich habe eine Klasse die wiederum eine verkettete Liste hat, die Sockets verwaltet.
    Das heisst, der Socket 3 kann geschlossen werden bevor der Socket 4 beendet ist.
    Also fällt select schonmal raus (oder hab ich das falsch verstanden?)!
    Ich hab also eine schleife, die ständig ein Socket nach dem anderen abfrägt.
    So jetzt hier meine Verständnisprobleme:
    Wartet ein Socket bis ich recv aufgerufen hab, oder gehen Daten verloren?
    wenn ich den pthread starte, läuft erst der pthread ab, und dann läuft mein Mainprog weiter..
    Ich will aber, das der mainproc und der Pthread gleichzeitig laufen.
    DIe Doku hab ich mir schon zu gemüte gezogen und auch die FAQs aber ab leider nichts gefunden!
    Und noch ne Frage, gibt es eine Funktion mit der man nachfragen kann ob ein neuer Client connecten will?
    Da accept ja solange blockt bis er etwas zum verbinden gefunden hat.
    Noch ein paar Zusatzinfos:
    Die Sockets sind NON_BLOCKING eingestellt.
    Danke schonmal im vorraus!

    0
  • R

    Ich habe eine Klasse die wiederum eine verkettete Liste hat, die Sockets verwaltet.
    Das heisst, der Socket 3 kann geschlossen werden bevor der Socket 4 beendet ist.
    Also fällt select schonmal raus (oder hab ich das falsch verstanden?)!

    select ist nicht abhängig davon wann welcher Socket geschlossen wird. Schau dir mal man: select(2) an, ansonsten gibt es noch man: poll(2); Ich muss mal schauen, irgend wo hatte ich einen guten Link zu dem Thema.

    Wartet ein Socket bis ich recv aufgerufen hab, oder gehen Daten verloren?

    Die Daten werden vom Kernel gebuffert, wobei der Buffer auch überfüllen kann, wenn du die Verbindung lange nicht abfragst

    wenn ich den pthread starte, läuft erst der pthread ab, und dann läuft mein Mainprog weiter..
    Ich will aber, das der mainproc und der Pthread gleichzeitig laufen.

    eigentlich sollten die parallel laufen und nicht nacheinander, da musst du irgend etwas falsch gemacht haben

    Und noch ne Frage, gibt es eine Funktion mit der man nachfragen kann ob ein neuer Client connecten will?
    Da accept ja solange blockt bis er etwas zum verbinden gefunden hat.

    wenn du mit select oder poll prüfst, wird AFAIK auf dem Socket gemeldet, dass jemand sich verbinden will. Aber ich bin mir da nicht mehr sicher

    Ich empfehle dir folgendes Buch, dass ist eigentlich das Standard Werk für das Thema und in jeder Newsgroup findest du Hinweise darauf. Der Kauf lohnt sich, da steht wirklich alles was du wissen musst drin
    UNIX Network Programming | ISBN: 0131411551

    0
  • N

    kingruedi schrieb:

    Die Daten werden vom Kernel gebuffert, wobei der Buffer auch überfüllen kann, wenn du die Verbindung lange nicht abfragst

    nicht bei tcp. wenn der buffer voll ist wird das dem anderen tcp mitgeteilt (window size == 0) und das sendet erst wieder was wenn es darf (window size < 0).
    bei udp läuft das anders. da gibt es meistens einen buffer-pool, in dem empfangene pakete gesammelt werden. die ältesten pakete fliegen raus, wenn lange nichts abgeholt wurde.

    0
  • R

    @net
    ich habe ja nichts anderes behauptet

    0
  • N

    kingruedi schrieb:

    @net
    ich habe ja nichts anderes behauptet

    hast du nicht behauptet dass der puffer überlaufen kann?
    macht er aber nicht.
    wie gesagt, die tcp's wissen immer wieviel platz der andere noch hat.

    0
  • R

    überfüllen hab ich gesagt, nicht das Zwangsweise Packete weggeworfen werden. Bei TCP würde so ein Verhalten ja die ganze Idee hinter dem Protokoll korrumpieren.

    0
  • S

    OK, für alle die das selbe problem haben;
    http://www.lowtek.com/sockets/select.html
    http://www.die.net/doc/linux/man/man2/select.2.html
    http://www-user.tu-chemnitz.de/~roej/socket.html
    http://www.ecst.csuchico.edu/~beej/guide/net/html/advanced.html#select
    http://www.zotteljedi.de/doc/socket-tipps/index.html
    http://www.pc-adviser.de/socket_programmierung.html

    Sodele, damit müsste man eigentlich alles hinkriegen.
    Hab es auf jedenfall jetzt geschafft!
    Nur noch eine letzte Frage:
    Wie kann ich schauen, ob der Socket noch aktiv ist?
    Also praktisch so ein socket=ifclientstillalive???
    Weil das ganze per recv zu lösen ja nicht ganz sauber sit!

    0
  • N

    kingruedi schrieb:

    überfüllen hab ich gesagt....

    ja, und das passiert eben nicht.

    0
  • R

    net schrieb:

    kingruedi schrieb:

    überfüllen hab ich gesagt....

    ja, und das passiert eben nicht.

    doch. Überfüllen impliziert nicht wegwerfen, sondern bedeutet so viel wie voll! Man bist du kleinlich

    0
Anmelden zum Antworten