[c] consiglio su app socket :)

[aeroxr1]

Io pensavo ad unica send in cui inviavo un buffer
char *buffer[256]

fino alla lunghezza riempita

5cpippo

E di là 1 recv per ricevere 5c (cavolo in effetti sono due byte rischierei un errore)

e un altra recv con len 5 per ricevere pippo .

In effetti è una soluzione sparta da bimbiminkia

Indeciso tra questa soluzione e tra l'inviare due send una per la lunghezza e una per il msg + usare una variabile per gli stati

Devo scegliere una via e portarla avanti senza guardarmi indietro

[van9]

Originariamente inviato da Daniels118

struct message_header
{
    uint32_t length;
    char variable_message[0]; // nn ricordo ma dovrebbe funzionare su C99
};

In pratica inserisci nella struttura un campo che il compilatore interpreta come un array di char (attenzione, un array in-place, non un puntatore ad un array posizionato chissà dove), ma non ne definisci la lunghezza, poi a runtime allochi la struttura con dello spazio eccedente ed accedi al campo sforando oltre la dimensione teorica (0).
Se da qualche errore di compilazione si può tranquillamente definire l'array di lunghezza 1 e poi ricordarsi di allocare un byte in meno (ma anche se ci dimentichiamo non satureremo la memoria per un solo byte).

La dimensione a zero non è mai stata valida per lo standard - un compilatore (no estensioni ovviamente) che non emette un warning in questo caso è da buttare. La dimensione ad uno è legale, ma invoca undefined behavior quando vai ad accedere oltre il primo elemento e se le ottimizzazioni sono attive può accadere di tutto. La cosa giusta è "char variable_message[];" usando C99. Se C99 non è un'opzione si usa la dimensione ad uno ma è meglio controllare cosa combina il compilatore.

C and C++, where (almost) everything is not what it seems...

[Oceans11]

Sì scusate, non stavo tenendo conto della select.
Il codice rimane quello, con l'aggiunta del controllo su FD_ISSET e il settaggio delle opportune variabili di stato, che a mio parere sono obbligatorie.
La dimensione del buffer di invio è irrilevante, mentre in ricezione te ne servono 2 di buffer: uno per dimensione oaylod + comando (se ha dimensione fissa) e il secondo che allochi a runtime in base a ciò che hai ricevuto.
Questo vuol dire che oltre al file descriptor, il server deve mantenere, per ogni connessione, la dimensione del payload, il comando e il buffer del payload (almeno parziale).
Ti suggerirei una struct che contenga il tutto e funzioni per serializzare/deserializzare i suoi dati.

Se questa soluzione non ti piace, puoi dare uno sguardo all'opzione del socket SO_RCVLOWA che ti permette di impostare il valore minimo in byte di soglia necessario a far ritornare la select. Non ho mai provato e non mi sento di consigliarlo.

[Daniels118]

Originariamente inviato da aeroxr1

[..]
Indeciso tra questa soluzione e tra l'inviare due send una per la lunghezza e una per il msg + usare una variabile per gli stati

Come già detto, dovendo fare la conversione del numero ti consiglio le due send, semplicemente per comodità... potremmo fare anche delle considerazioni su cosa sia meglio o peggio in termini di performance, ma visto che non stai scrivendo un server per streaming video direi che le performance possono passare in secondo piano.

Se questa soluzione non ti piace, puoi dare uno sguardo all'opzione del socket SO_RCVLOWA che ti permette di impostare il valore minimo in byte di soglia necessario a far ritornare la select. Non ho mai provato e non mi sento di consigliarlo.

Questa non la sapevo, ma leggo che su linux il valore è bloccato ad 1 byte... peccato.

Ribadisco anche io la necessità di una variabile di stato per ogni connessione, naturalmente solo sul client.

[aeroxr1]

ok quindi credo farò così :
- due send una fissa di un byte con la dimensione del campo successivo che verrà inviata con la send subito dopo
- sul server terrò una lista con un elemento per ogni client , contenente i vari buffer per ogni client e la variabile di stato che mi dirà in che punto sono della comunicazione client server
- la variabile comando potrei inviarla successivamente tanto il primo comando è per forza di cose l'invio dello username
- dopo negli invii successivi andrò a vedere cosa c'è nel campo data e qui ci sarà il comando e per ogni comando mi sposterò nello stato opportuno

Fin qui ragiono male ? (poi per carità lo deve vedere in pratica, però l'idea sarebbe questa )

per serializzare i dati della struct che andrò ad inviare passo passo, dato che la mia struct conterrà solo caratteri [username e comandi] e numeri interi , potrei usare per questi ultimi le semplici funzioni htons() , ntohs() , htonl() e ntohl() ?

E un ultima cosa la creazione del buffer dinamico sul server, io inizialmente pensavo di creare una struttura con all'interno un campo username[256], comando ecc ecc.
Allocando staticamente i vettori con uno spazio grande a sufficienza, e non usare la creazione dinamica, poichè non sono capace a creare un allocazione dinamica di stringhe-vettori in C , però mi rendo conto che lo spreco è alto

Vabbè sarà il caso di capire come creare allocazione dinamica di vettori

[Daniels118]

No, dai, studia prima l'allocazione dinamica e poi ti cimenti coi socket!
Per il futuro, quando vorrai fare delle ottimizzazioni, ricordati di non allocare e deallocare continuamente, sono operazioni che costano, pensa bene dove vale la pena risparmiare e accorpa quello che si può accorpare.

[van9]

Originariamente inviato da Daniels118

( SO_RCVLOWAT )
Questa non la sapevo, ma leggo che su linux il valore è bloccato ad 1 byte... peccato.

Quella è SO_SNDLOWAT, di SO_RCVLOWAT puoi fare il set ma poi non hai signaling affidabile e quindi serve a nulla.

[Daniels118]

Originariamente inviato da van9

Quella è SO_SNDLOWAT, di SO_RCVLOWAT puoi fare il set ma poi non hai signaling affidabile e quindi serve a nulla.

Qui leggo:

SO_RCVLOWT
[..] Note that not all implementations allow this option to be set.

Ancora, dalle manpages:

socket(7):
"SO_RCVLOWAT and SO_SNDLOWAT
Specify the minimum number of bytes in the buffer until the socket layer will
pass the data to the protocol (SO_SNDLOWAT) or the user on receiving
(SO_RCVLOWAT). These two values are initialized to 1. SO_SNDLOWAT is not
changeable on Linux (setsockopt(2) fails with the error ENOPROTOOPT).
SO_RCVLOWAT is changeable only since Linux 2.4. The select(2) and poll(2) sys-
tem calls currently do not respect the SO_RCVLOWAT setting on Linux, and mark a
socket readable when even a single byte of data is available. A subsequent
read from the socket will block until SO_RCVLOWAT bytes are available."

In altre parole SO_RCVLOWAT ha effetto solo sulla read (e su Linux solo a partire dalla versione 2.4), mentre su select e poll non ha alcun effetto.

[aeroxr1]

Originariamente inviato da Daniels118

No, dai, studia prima l'allocazione dinamica e poi ti cimenti coi socket!
Per il futuro, quando vorrai fare delle ottimizzazioni, ricordati di non allocare e deallocare continuamente, sono operazioni che costano, pensa bene dove vale la pena risparmiare e accorpa quello che si può accorpare.

In C non mi è così banale allocare dinamicamente uno spazio indefinito, cioè faccio per dire lo username può essere 10 caratteri,ma anche 40.
Quindi non so di quanto spazio allocare in memoria con la malloc
Cercando su internet ho letto della funzione realloc, in pratica gli si assegna un blocco di dimensioni x e poi se non basta con la realloc si riassegna un altro spazio contiguo (se esiste , già questa cosa mi lascia perplesso ) . Però non ho trovato la maniera di creare un buffer perfettamente adatto all'input.

Però riflettendoci in questo caso saprei quanti byte mi arrivano quindi creo una porzione per quei byte e la riempio
Il problema è più sul client , però li metto un buffer grande e grosso

[Daniels118]

La programmazione lascia abbastanza spazio alla fantasia, dipende dalla logica che vuoi utilizzare, comunque non restare nell'indecisione, intraprendi una strada che ritieni corretta, poi se ti si presenteranno dei problemi troverai il modo di affrontarli. Anche se commetti un errore non ti avvilire, sbagliando si impara

[aeroxr1]

Non avessi sempre delle scadenze vicine da rispettare il tutto sarebbe meno stressante

COmunque grazie a tutti Provo un pò a mettere le mani nel codice vediamo che ne viene fuori Mi farò sicuramente risentire per rompervi le scatole con altri dubbi

[aeroxr1]

Non avessi sempre delle scadenze vicine da rispettare il tutto sarebbe meno stressante

COmunque grazie a tutti Provo un pò a mettere le mani nel codice vediamo che ne viene fuori Mi farò sicuramente risentire per rompervi le scatole con altri dubbi

[van9]

Originariamente inviato da Daniels118

Qui leggo:

Si non è obbligatoria per dirsi POSIX, è solo un sistema opzionale per risparmiare copie dal kernel alla userland.

Ancora, dalle manpages:

In altre parole SO_RCVLOWAT ha effetto solo sulla read (e su Linux solo a partire dalla versione 2.4), mentre su select e poll non ha alcun effetto.

Ah era nella man page, e io che d'istinto m'ero letto i sorgenti... babbè.

[van9]

Originariamente inviato da aeroxr1

In C non mi è così banale allocare dinamicamente uno spazio indefinito, cioè faccio per dire lo username può essere 10 caratteri,ma anche 40.

Un ottimo motivo per imparare a usare da subito librerie di qualità comprovata come Vstr o Bstring, e poi studiarsene gli internals e scriversi le proprie per imparare.

[aeroxr1]

Originariamente inviato da van9

Un ottimo motivo per imparare a usare da subito librerie di qualità comprovata come Vstr o Bstring, e poi studiarsene gli internals e scriversi le proprie per imparare.

Grazie a tutti per i suggerimenti Siete grandiosi
In molti forum se avessi chiesto le stesse cose mi avrebbero dato dell'ignorante , voi invece mi avete dato una grande mano !
Grazie veramente di cuore

[aeroxr1]

Prendendo un pò di vostri suggerimenti ho iniziato a cercare di mettere in pratica questa idea:

Lato Client:
- send comando (1byte)
- send dimensione dati (1byte)
- send dati (dimensione variabile)

Lato Server:
- recv comando (1byte)
- recv dimensione dati (1byte)
- recv dati (dimensione variabile)

una struttura lato server contenente :
- variabile comando
- variable lunghezza dati
- buffer dinamico contentente i dati
- variabile di stato

la variabile di stato pensavo di farla da 0 a 3 dove
0 attesa comando, 1 attesa dimensione dati , 2 attesa dati, 3 esecuzione comando (forse lo stato 3 è evitabile)

- Voi che dite sono troppe tre recv due delle quali usate per ricevere un byte per volta ?
- e anche la variabile lunghezza dati pensavo di inviarla sempre anche quando il campo dati contiene un dato di dimensione 0 cioè vuoto e quando il campo dati contiene 1 solo byte . Dite che è uno spreco ?

[Daniels118]

La struttura sul server deve avere un'ulteriore variabile che conserva la lunghezza dei dati effettivamente ricevuti, perché il server deve rimanere nello stato "2 attesa dati" fino a quando i dati ricevuti raggiungono la lunghezza dati prevista.
Sul client vale lo stesso discorso, e non avendo il problema di dover gestire più connessioni puoi mettere la recv in un loop.
Lo stato 3 lo eviterei, quando i dati ricevuti raggiungono la lunghezza prevista puoi eseguire il comando e reimpostare lo stato zero.
Per me non c'è alcun motivo per non usare una recv per ogni dato.
La lunghezza dato la invierei sempre, in questo modo non c'è bisogno di controllare che tipo di comando è arrivato.

[aeroxr1]

Esatto la lunghezza dato pensavo proprio di inviarla sempre per quel motivo se no dovrei fare un doppio controllo sul comando.
E la variabile che hai detto mi ero scordata di scriverla XD

Io però lato server hi creato una struttura ad hoc per ogni client mentre lato client no.
Sulla serializzazione delle strutture non avendolo mai fatto mi incuriosisce , ma dovrei informarmi .
Lato client c'è una connessione UDP verso un altro client
Devo un attimo riflettere se mentre riceve ha bisogno anche di comunicare con l'altro client o no. In caso positivo devo gestire la recv per evitare il loop :/
Vedrò !

Inviato dal mio Galaxy Nexus utilizzando Tapatalk

[WarDuck]

Originariamente inviato da van9

La dimensione a zero non è mai stata valida per lo standard - un compilatore (no estensioni ovviamente) che non emette un warning in questo caso è da buttare. La dimensione ad uno è legale, ma invoca undefined behavior quando vai ad accedere oltre il primo elemento e se le ottimizzazioni sono attive può accadere di tutto. La cosa giusta è "char variable_message[];" usando C99. Se C99 non è un'opzione si usa la dimensione ad uno ma è meglio controllare cosa combina il compilatore.

C and C++, where (almost) everything is not what it seems...

Ho provato su Debian 7 con GCC 4.7 e con i flag -Wall -Wextra non riporta nulla (non ho dovuto neanche passargli std C99).

Ora giusto per curiosità provo sulle ultime versioni di clang e Visual Studio 2013 .

Edit: neanche Visual Studio si lamenta (sempre abilitando tutti i Warning), sarà perché usa un compilatore C++.

Edit2: neanche llvm 3.4, sempre passando -Wall -Wextra.

In pratica possiamo buttare tutti i compilatori esistenti .

[nico159]

Originariamente inviato da WarDuck

Ho provato su Debian 7 con GCC 4.7 e con i flag -Wall -Wextra non riporta nulla (non ho dovuto neanche passargli std C99).

Ora giusto per curiosità provo sulle ultime versioni di clang e Visual Studio 2013 .

Edit: neanche Visual Studio si lamenta (sempre abilitando tutti i Warning), sarà perché usa un compilatore C++.

Edit2: neanche llvm 3.4, sempre passando -Wall -Wextra.

In pratica possiamo buttare tutti i compilatori esistenti .

Devi usare -Wpedantic

warning: ISO C++ forbids zero-size array ‘variable_message’ [-Wpedantic]

Issue all the warnings demanded by strict ISO C and ISO C++; reject all programs that use forbidden extensions, and some other programs that do not follow ISO C and ISO C++. For ISO C, follows the version of the ISO C standard specified by any -std option used.