myouness27 schrieb:
hallo r0nny ,
danke für deine Antwort hier ist ein Teil des Programms wo ich darauf gestoßen bin .
siehe
r0nny schrieb:
PS: mit grep hättest du das in 30 s rausgefunden ;P
und bitte benutz Code-Tags.
BehindTheScenes schrieb:
2. Wie kann ich das Verbinden zum Server nur von Localhost erlauben?
Ersetze in der sockaddr_in-Variable, die du an bind() übergibst, INADD_ANY durch INADDR_LOOPBACK.
atomfish schrieb:
du kannst auch pfeifen nehmen
named pipes auch FIFO genannt.
... und es gehen auch unnamed pipes (finde ich persönlich schöner und flexibler als named pipes). Siehe hierzu pipe(2). Der Vater/Parent-Prozess erzeugt eine pipe pro Kind/Child-Prozess und vererbt diese beim fork(). Er selbst schließt seinen Schreibkanal, der Child-Prozess schließt den Lesekanal. Dann gibt es eine Schreib-Lese-Verbindung vom Child zum Parent. Will man auch noch eine Rückrichtung haben, so benutzt man hierfür eine zweite Pipe.
... wie der geneigte Leser unschwer erkennen kann, ist eine solche Programmierung nicht ganz einfach. Anfänger sollten sich einfach merken, dass da noch etwas anderes geht ...
bloodshower schrieb:
Hallo!
@StreamKid: Ich würde nicht sagen, dass CDK einfacher handzuhaben ist. Es bietet eine Menge vorgefertigter Widgets an, spart sich somit einige Funktionsaufrufe. Ncurses und CDK sind aber beide relativ gut dokumentiert.
Gruss
Michael
Hallo noch einmal.
Ich hab beides verdendet..
Ncurses fand ich besser
aber, das ist nicht was ich eigentlich wollte...
verwendet jemand tmsn?
ich wollte ein solches gui machen... ich weiss, das tmsnc kein ncurses order curses verwendett, aber ich wollte das mit curses machen... hatt jemand eine idee?
Entschuldige bitte, aber AUDIO/VIDEO über UDP? Das will mir nicht einleuchten. Bei Video- und Audio-Daten ist es essentiell, daß alle Daten in der richtigen Reihenfolge und vollständig ankommen. Besonders wichtig ist das, wenn Du komprimierte Ströme überträgst (beispielsweise MPEG/2/4), weil dort vorangegangene Bilder oder Töne als Grundlage für neue Bilder oder Töne dienen (siehe I/B/P-Frames, MP3-Komprimierung).
Wenn du unkomprimierte Vollbilder überträgst, bekommst du noch ein ganz anderes Problem. Sagen wir, du überträgst Video und Ton unkomprimiert, mit einer Auflösung von 640x480x32 bei 25 fps und 44KHz / 16Bit / Stereo für den Ton.
Da sind wir schon für die Nutzdaten bei 29,5 MB/s, das schafft ein 100 MBit/s Netzwerk schon gar nicht mehr.
Also doch die komprimierten Daten, und damit werden Flußkontrolle und Verbindungsüberwachung erforderlich. Wenn du Point-To-Multipoint streamen willst, müsstest du diese selbst implementieren, bei einfachen Point-To-Point Verbindungen wäre TCP die bessere Lösung...
dcmaster schrieb:
danke, xbindkey ist richtig cool, ist sowas auch auf windows mit c++ möglich?
Bestimmt. Frag am besten mal bei den Kollegen im WinAPI-Forum.
Hmm, ich versteh dich glaube ich nicht ganz:
In Zeile 3 erstelle ich eine Variable "len" vom Typ "socklen_t":
socklen_t len;
Und dann in Zeile 13 übergebe ich als letzten Parameter die Adresse von "len".
Und diese Zeile ist doch dann auch für die Initialisierung zuständig!?
Bitte sag mir wenn ich da auf dem Holzweg bin. Wie gesagt, momentan kann ich mit deiner Lösung leider nichts anfangen. *schäm*
[EDIT] Ahhhh, SChande über mein Haupt! Ich hab total vergessen, dass da ja bereits die Größe drinstehen muss und dass nicht die Funktion recvfrom() dafür verantwortlich ist, diese Variable zu füllen. Vielen Dank!!!
Danke!
ajax schrieb:
oh das ist noch was anderes von vorher...
print("%s", errno);
muesste gehen?
??? schnon mal von man: perror(3) oder man: strerror(3) gehört?
ernno ist auch eine int Variable!
JustOlli schrieb:
Was meinste denn genau mit Pipes? Named-Pipes wie man sie mit mkfifo erzeugen kann?
Dann doch zur not einfach testen:
i=0; while [ $i -lt 100 ]; do mkfifo /tmp/pipe_$i; i=$(($i+1)); done
... ich gehe mal davon aus, das @Luutsch pipes meint, die man per Programm, z.B. mittels pipe(2), öffnet. Mittels pipe(2) belegt man natürlich immer zwei Filedescriptoren auf einen Schlag. Named pipes öffnet man im Programm mittels "normalen" open()/ bzw. fopen() Befehlen, sind folglich bzgl. Anzahl geöffneter Filedescriptoren wie normale Files zu betrachten.
Übrigens: Mit dem Beispiel-Script (... "mkfifo" ...) kann man nicht testen, wieviel geöffnete named pipes ein Prozess verkraften kann. Öffnen tut man sie nämlich erst dann, wenn man auf sie zugreift (lesen oder schreiben). Hiermit testet man also etwas völlig Anderes, nämlich nur, wieviel named pipes man überhaupt in einem Filesystem anlegen kann. Und das dürfte vorrangig von der maximalen Anzahl der Inodes (für dieses Filesystem) und, was eher vernachlässigbar ist, vom verfügbaren Plattenplatz diese Filesystems abhängen.
P.S.: named pipes lassen sich auf Shell-Ebene auch anlegen mittels "mknod", was der ursprüngliche Unix-Befehl ist. "mkfifo" ist von mknod abgeleitet.
Nein, so was habe ich noch nicht gesehen. SYSFUNC scheint irgend ein Macro zu sein. Woher hast du den Code? Schau dir mal an, wo das Macro definiert ist.
Mehr Informationen zu open findest du in der Manpage man: open(2)
Hab das Problem in den Griff bekommen. Man sollte halt im geshareten Objekt nicht mit new Speicher allokieren, der ist dann nämlich in einem nicht mehr geshareten Bereich und dupliziert sich mit fork gnadenlos
alexf schrieb:
(gdb) break main:238
dann kommt:
make breakpoint on future shared library load (y or [n])
was heisst das?
ich vermute die 238 bezieht sich auf die zeilennummer in der datei (main.c(pp)?)
wenn du die zeilen in einer datei ansprechen möchtest zum setzten eines breakpoints, musst du den dateinamen angeben.