Alcune domandine semplici sul C - Pagina 4

ilsensine · 29-10-2002, 16:37

Compila con -D_GNU_SOURCE

Cimmo · 29-10-2002, 17:04

Quote:

Originariamente inviato da ilsensine
[b]Compila con -D_GNU_SOURCE

Uh...funzia! Ma che vuol dire? Sul man non ho trovato niente...

ilsensine · 29-10-2002, 19:21

...segreti del mestiere

(...e una omissione/dimenticanza nella pagina man)

Cimmo · 29-10-2002, 19:45

Quote:

Originariamente inviato da ilsensine
[b]...segreti del mestiere

(...e una omissione/dimenticanza nella pagina man)

No dai adesso sono curioso...

ilsensine · 29-10-2002, 20:19

Alcune funzionalità delle libc sono proprie di standard particolari e non sono disponibili a meno di definire delle macro specifiche. Definendo _GNU_SOURCE hai accesso a tutte le funzionalità delle libc.
Altri esempi sono:
sched_yield()
formato esteso di sigaction
strndup
ecc.

Cimmo · 30-10-2002, 11:18

Se io ho un server con un certo indirizzo ip: e ho n figli che cercano di aprire listening socket in mutua esclusione senno' la bind si arrabbia, perche' assegna 2 volte lo stesso socketfd a 2 client differenti che si sono collegati?
C'e' qualche variabile che devo condividere con tutti gli n figli?

ilsensine · 30-10-2002, 12:37

Quando un processo forka, i due processi risultanti avranno una propria storia. Quindi un fd di uno sarà un descrittore a parte rispetto l'fd dell'altro, indipendentemente che abbiano o no lo stesso valore. Solo gli fd già aperti possono venir ereditati dal child, ma in tal caso viene in effetti duplicato il descrittore da condividere.

Cimmo · 30-10-2002, 12:53

Quote:

Originariamente inviato da ilsensine
[b]Quando un processo forka, i due processi risultanti avranno una propria storia. Quindi un fd di uno sarà un descrittore a parte rispetto l'fd dell'altro, indipendentemente che abbiano o no lo stesso valore. Solo gli fd già aperti possono venir ereditati dal child, ma in tal caso viene in effetti duplicato il descrittore da condividere.

Urca! Quindi se A1 si connette con B1 e A2 si vuole connettere con B2 non puo' sfruttare lo stesso socketfd della connessione A1-B1?
A1 e A2 sono figli di A con lo stesso indirizzo e stessa cosa dicasi per B1 e B2.

ilsensine · 30-10-2002, 13:43

Quote:

Urca! Quindi se A1 si connette con B1 e A2 si vuole connettere con B2 non puo' sfruttare lo stesso socketfd della connessione A1-B1?

No, devi fare una connect() a parte, altrimenti useresti lo stesso canale di comunicazione di A1, e succede un casino.

Cimmo · 30-10-2002, 13:54

Quote:

Originariamente inviato da ilsensine
[b]
No, devi fare una connect() a parte, altrimenti useresti lo stesso canale di comunicazione di A1, e succede un casino.

Infatti per ora il mio software ha un sacco di anomalie.
Per capire meglio se io ho A1 che si connette a B1 e voglio che anche A2 e B2 si connettano insieme devo fare 2 connessioni completamente differenti? Questo anche se sono entrambi figli di A (A1 e A2) e quindi hanno lo stesso indirizzo e porta ip?

In alternativa non e' fattibile che io allacci una connessione tra A e B (i padri) e poi tutti i figli di A (A1, A2...) possono usare il canale e cosi' anche tutti i figli di B (B1, B2...).
Questo e' molto importante, grazie ancora per rispondere sempre tempestivamente alle domane, sto facendo un progetto per niente semplice...

ilsensine · 30-10-2002, 14:11

Non capisco qual è il problema...
A dovrebbe stare in listen e creare un child ad ogni nuova connessione, ok?
Ogni figlio By di B effettua una connect() con A, il quale crea un child Ax per gestire la connessione...in genere si fa così

Cimmo · 30-10-2002, 14:18

Ok io invece prima creavo il figlio e poi la connessione veniva generata dallo stesso figlio, speravo poi di poter recuperare da un altro figlio la connessione avvenuta mantenendo lo stesso socketfd, ma cosi' non funzia...
ma io posso fare cosi'?

1) il padre crea il figlio
2) il figlio si mette in attesa che il padre gli procuri una connessione
3) il padre crea tutti i figli che si mettono in attesa
4) il padre si mette in attesa di una connessione appena gliene arriva una lui passa il numero del socketfd al/ai figlio/i interessati e poi ritorna al punto 4) cioe' in attesa di altre connessioni.

E' un po' diverso dal aspettare la connessione e poi creare, pero' mi sembra che il conto torni...o mi sbaglio?

ilsensine · 30-10-2002, 15:49

Ok certo, se vuoi perdere tutti i capelli prima del tempo, è la procedura migliore

Cimmo · 30-10-2002, 16:14

Quote:

Originariamente inviato da ilsensine
[b]Ok certo, se vuoi perdere tutti i capelli prima del tempo, è la procedura migliore

Alt...fermi tutti!
Ma se io devo fare gestire tutto dal padre, come faccio contemporaneamente a mettermi in ascolto e a connettermi? Questo perche' il programma che sto cercando di fare fa sia da server che da client, quindi fino a poco fa, un client si collegava al server (erano 2 figli differenti di 2 istante differenti non so se ho reso l'idea) ora pero' se il padre si mette in ascolto, quello si inchioda li' e come faccio contemporaneamente a cercare di connettermi?
ARGH AIUTO!

ilsensine · 30-10-2002, 16:26

Non intendevo di far fare tutto a un padre, ma di creare i child solo quando servivano, per uno scopo ben preciso, e in maniera che possano essere autonomi una volta creati e inizializzati.
Cmq dovresti analizzare l'opportunità di usare i pthread al posto di processi distinti (è più facile l'ipc, non serve shm, semafori o altro).

cionci · 30-10-2002, 16:47

Quote:

Originariamente inviato da Cimmo
[b]Alt...fermi tutti!
Ma se io devo fare gestire tutto dal padre, come faccio contemporaneamente a mettermi in ascolto e a connettermi?

Puoi fare un processo figlio che ascolta e che crea altri figli...
Il primo processo crea inoltre un altro processo figlio client quando serve (se puoi gestire più client contemporaneamente, altrimenti è lo stesso processo padre che fa da client)...

Segui il consiglio di ilsensine sui pthread... I thread a differenza dei processi sono a memoria comune

Cimmo · 30-10-2002, 18:02

Quote:

Originariamente inviato da cionci
[b]
Puoi fare un processo figlio che ascolta e che crea altri figli...
Il primo processo crea inoltre un altro processo figlio client quando serve (se puoi gestire più client contemporaneamente, altrimenti è lo stesso processo padre che fa da client)...

Segui il consiglio di ilsensine sui pthread... I thread a differenza dei processi sono a memoria comune

Il problema e' questo (e' difficile da spiegare) ogni istanza del mio software ha una parte server e una client. Siccome il server puo' ricevere una connessione che puo' servire anche al client volevo fargli usare la stessa connessione senza fare casini. Quindi all'inizio facevo creare un figlio per ogni client/server e il primo che si connetteva dava il socketfd all'altro, ma questo mi sembra di aver capito non funzia.
Ora:
se io creo un primo figlio che si mette in ascolto e poi appena si connette a sua volta crea un figlio che gestisce la connessione ok questo il lato server, il lato client pero' dove lo metto? Faccio fare un secondo figlio al padre e poi cerco a sua volta di connettermi e se ci riesco creo un figlio? Pero' in questo caso e' sempre la stessa storia la connessione raggiunta dal client o dal server non e' gestibile dall'altra parte.
Mi sono spiegato? Se no vi faccio pure un disegno pure di farvi capire...rispondetemi sono in kernel panic

cionci · 30-10-2002, 18:13

Spiegami meglio...
Il server quante connessioni accetta ? Una sola ?
E il client a quenti server si può conenttere ?

Cimmo · 30-10-2002, 18:45

Quote:

Originariamente inviato da cionci
[b]Spiegami meglio...
Il server quante connessioni accetta ? Una sola ?
E il client a quenti server si può conenttere ?

Il server ne accetta una sola alla volta, ma alla fine ne possono arrivare piu' d'una.
Il client puo' anche lui connettersi da 0 a n host. Siccome molte volte il client e il server della stessa istanza del software possono (ma non e' detto) connettersi allo stesso host (che altro non e' che un'altra istanza del medesimo software) vorrei che questa connessione venga condivisa!
Ti spedisco anche un disegno scannerizzato per rendere l'idea...immagina che di istanze del mio software ce ne puo' essere da 1 a n anche per quella.
Spero di essere stato piu' chiaro...fammi sapere...

cionci · 30-10-2002, 19:05

Un processo "listener" sta in ascolto con la accept su una porta...
Ogni volta che riceve una connessione in ingresso lancio un processo "chat" (la chiamo chat anche se magari no lo è, ma rende bene l'idea)...

Un altro processo chiamo "connector" ha il compito di creare una nuova connessione verso un "listener"...

Il processo "chat" è lo stesso sia per il "listener" che per il "connector" ed ha bisogno solamente del socket creato da uno dei due processi...
Su questo socket viaggeranno sia i dati in uscita che quelli in ingresso...

Se non hai grossi problemi di prestazioni credo che tu possa usare sia send che receive non bloccanti nello stesso processo...
Oppure lanci un altro processo che si occupa di trasmettere e ricevere i dati...con send bloccanti e receive non bloccanti...

29-10-2002, 16:37	#61
ilsensine Senior Member Iscritto dal: Apr 2000 Città: Roma Messaggi: 15625	Compila con -D_GNU_SOURCE __________________ 0: or %edi, %ecx; adc %eax, (%edx); popf; je 0b-22; pop %ebx; fadds 0x56(%ecx); lds 0x56(%ebx), %esp; mov %al, %al andeqs pc, r1, #147456; blpl 0xff8dd280; ldrgtb r4, [r6, #-472]; addgt r5, r8, r3, ror #12

29-10-2002, 19:21	#63
ilsensine Senior Member Iscritto dal: Apr 2000 Città: Roma Messaggi: 15625	...segreti del mestiere (...e una omissione/dimenticanza nella pagina man) __________________ 0: or %edi, %ecx; adc %eax, (%edx); popf; je 0b-22; pop %ebx; fadds 0x56(%ecx); lds 0x56(%ebx), %esp; mov %al, %al andeqs pc, r1, #147456; blpl 0xff8dd280; ldrgtb r4, [r6, #-472]; addgt r5, r8, r3, ror #12

29-10-2002, 20:19	#65
ilsensine Senior Member Iscritto dal: Apr 2000 Città: Roma Messaggi: 15625	Alcune funzionalità delle libc sono proprie di standard particolari e non sono disponibili a meno di definire delle macro specifiche. Definendo _GNU_SOURCE hai accesso a tutte le funzionalità delle libc. Altri esempi sono: sched_yield() formato esteso di sigaction strndup ecc. __________________ 0: or %edi, %ecx; adc %eax, (%edx); popf; je 0b-22; pop %ebx; fadds 0x56(%ecx); lds 0x56(%ebx), %esp; mov %al, %al andeqs pc, r1, #147456; blpl 0xff8dd280; ldrgtb r4, [r6, #-472]; addgt r5, r8, r3, ror #12

30-10-2002, 12:37	#67
ilsensine Senior Member Iscritto dal: Apr 2000 Città: Roma Messaggi: 15625	Quando un processo forka, i due processi risultanti avranno una propria storia. Quindi un fd di uno sarà un descrittore a parte rispetto l'fd dell'altro, indipendentemente che abbiano o no lo stesso valore. Solo gli fd già aperti possono venir ereditati dal child, ma in tal caso viene in effetti duplicato il descrittore da condividere. __________________ 0: or %edi, %ecx; adc %eax, (%edx); popf; je 0b-22; pop %ebx; fadds 0x56(%ecx); lds 0x56(%ebx), %esp; mov %al, %al andeqs pc, r1, #147456; blpl 0xff8dd280; ldrgtb r4, [r6, #-472]; addgt r5, r8, r3, ror #12

30-10-2002, 14:11	#71
ilsensine Senior Member Iscritto dal: Apr 2000 Città: Roma Messaggi: 15625	Non capisco qual è il problema... A dovrebbe stare in listen e creare un child ad ogni nuova connessione, ok? Ogni figlio By di B effettua una connect() con A, il quale crea un child Ax per gestire la connessione...in genere si fa così __________________ 0: or %edi, %ecx; adc %eax, (%edx); popf; je 0b-22; pop %ebx; fadds 0x56(%ecx); lds 0x56(%ebx), %esp; mov %al, %al andeqs pc, r1, #147456; blpl 0xff8dd280; ldrgtb r4, [r6, #-472]; addgt r5, r8, r3, ror #12

30-10-2002, 11:18	#66
Cimmo Senior Member Iscritto dal: Jan 2001 Città: California Messaggi: 7174	Se io ho un server con un certo indirizzo ip: e ho n figli che cercano di aprire listening socket in mutua esclusione senno' la bind si arrabbia, perche' assegna 2 volte lo stesso socketfd a 2 client differenti che si sono collegati? C'e' qualche variabile che devo condividere con tutti gli n figli?

30-10-2002, 14:18	#72
Cimmo Senior Member Iscritto dal: Jan 2001 Città: California Messaggi: 7174	Ok io invece prima creavo il figlio e poi la connessione veniva generata dallo stesso figlio, speravo poi di poter recuperare da un altro figlio la connessione avvenuta mantenendo lo stesso socketfd, ma cosi' non funzia... ma io posso fare cosi'? 1) il padre crea il figlio 2) il figlio si mette in attesa che il padre gli procuri una connessione 3) il padre crea tutti i figli che si mettono in attesa 4) il padre si mette in attesa di una connessione appena gliene arriva una lui passa il numero del socketfd al/ai figlio/i interessati e poi ritorna al punto 4) cioe' in attesa di altre connessioni. E' un po' diverso dal aspettare la connessione e poi creare, pero' mi sembra che il conto torni...o mi sbaglio?

30-10-2002, 15:49	#73
ilsensine Senior Member Iscritto dal: Apr 2000 Città: Roma Messaggi: 15625	Ok certo, se vuoi perdere tutti i capelli prima del tempo, è la procedura migliore __________________ 0: or %edi, %ecx; adc %eax, (%edx); popf; je 0b-22; pop %ebx; fadds 0x56(%ecx); lds 0x56(%ebx), %esp; mov %al, %al andeqs pc, r1, #147456; blpl 0xff8dd280; ldrgtb r4, [r6, #-472]; addgt r5, r8, r3, ror #12

30-10-2002, 16:26	#75
ilsensine Senior Member Iscritto dal: Apr 2000 Città: Roma Messaggi: 15625	Non intendevo di far fare tutto a un padre, ma di creare i child solo quando servivano, per uno scopo ben preciso, e in maniera che possano essere autonomi una volta creati e inizializzati. Cmq dovresti analizzare l'opportunità di usare i pthread al posto di processi distinti (è più facile l'ipc, non serve shm, semafori o altro). __________________ 0: or %edi, %ecx; adc %eax, (%edx); popf; je 0b-22; pop %ebx; fadds 0x56(%ecx); lds 0x56(%ebx), %esp; mov %al, %al andeqs pc, r1, #147456; blpl 0xff8dd280; ldrgtb r4, [r6, #-472]; addgt r5, r8, r3, ror #12

30-10-2002, 18:13	#78
cionci Senior Member Iscritto dal: Apr 2000 Città: Vicino a Montecatini(Pistoia) Moto:Kawasaki Ninja ZX-9R Scudetti: 29 Messaggi: 53971	Spiegami meglio... Il server quante connessioni accetta ? Una sola ? E il client a quenti server si può conenttere ?

30-10-2002, 19:05	#80
cionci Senior Member Iscritto dal: Apr 2000 Città: Vicino a Montecatini(Pistoia) Moto:Kawasaki Ninja ZX-9R Scudetti: 29 Messaggi: 53971	Un processo "listener" sta in ascolto con la accept su una porta... Ogni volta che riceve una connessione in ingresso lancio un processo "chat" (la chiamo chat anche se magari no lo è, ma rende bene l'idea)... Un altro processo chiamo "connector" ha il compito di creare una nuova connessione verso un "listener"... Il processo "chat" è lo stesso sia per il "listener" che per il "connector" ed ha bisogno solamente del socket creato da uno dei due processi... Su questo socket viaggeranno sia i dati in uscita che quelli in ingresso... Se non hai grossi problemi di prestazioni credo che tu possa usare sia send che receive non bloccanti nello stesso processo... Oppure lanci un altro processo che si occupa di trasmettere e ricevere i dati...con send bloccanti e receive non bloccanti...

Strumenti
Mostra una versione stampabile Invia questa pagina per email