[c] consiglio su app socket :)

[Daniels118]

@Mettiu_

non c'è ragione per cui l'int possa essere spezzettato se il trasmettitore fà una sola send().

Ti invito a vedere questo esempio che avevo fatto:

Originariamente inviato da Daniels118

[..] immagina questa situazione con dei pacchetti da 512 byte:
1) invio un messaggio da 506 byte + 4 per la lunghezza, ma il pacchetto non parte perché il buffer ha ancora spazio per 2 byte e il sistema aspetta ancora un po' per vedere se si riempie;
2) subito dopo invio un messaggio di 100 byte + 4 per la lunghezza;
3) il sistema bufferizza i dati e li divide in due pacchetti, il primo contiene 4+506+2 byte, il secondo ne contiene 2+100;
4) il client riceve il primo pacchetto e ne legge 4 byte, vede che il dato è lungo 506 byte e li legge;
5) il buffer contiene ancora 2 byte, quindi il client prova a leggere 4 byte, ma ne ottiene solo due perché il secondo pacchetto non è ancora arrivato, quindi interpreta male la lunghezza del dato... da qui in poi si scatena l'inferno

Questo non significa che facendo una sola recv il programma non funziona mai, ma significa che a volte potrebbe funzionare e a volte no. Per l'esattezza se siamo fortunati potrebbe anche funzionare sempre, se si verificano le condizioni che avevo in un post successivo.

[Daniels118]

No. Come dicevo, in C99 "char message[]" come ultimo membro di una struct e quando effettivamente preceduto da (almeno) un altro named member non è un puntatore ma un incomplete array type che prende il nome di "flexible array member". Studialo nello standard.

Ammetto di essere rimasto qualche standard indietro, se ne avrò la necessità mi aggiornerò

L' "equivalenza" tra array e puntatori non esiste - non sono la stessa cosa. Punto. Sono intercambiabili in alcune circostanze, che è molto diverso. Possibile sia così difficile da capire?

Non è difficile da capire, come giustamente affermi dipende dalle circostanze, purtroppo l'uso improprio di alcuni termini a volte diventa un'abitudine.

[aeroxr1]

Originariamente inviato da Daniels118

Si, se usi gli shift puoi fare a meno di ntohl.

ma alla fine comunque un ntohl lo devo fare o sbaglio ?

cioè io shifto il valore che ho ricevuto di (8bit*il numero di byte letti) e poi faccio la or con i byte letti al nuovo giro.

Ma con questa soluzione ho due dubbi :

- ammettendo di aver fatto la procedura corretta alla fine quando ho il dato definitivo devo comunque usare ntohl sulla variabile contenente la lettura finale o sbaglio ?

- questo metodo funziona se il primo byte ricevuto è il byte più significativo, non so come mai ma nella mia testa ho dato per scontato funzionasse così, ma è realmente così ?

[Daniels118]

No, se usi lo shift non c'è bisogno di usare ntohl perché sei tu stesso a controllare l'ordine dei byte.

[aeroxr1]

Originariamente inviato da Daniels118

No, se usi lo shift non c'è bisogno di usare ntohl perché sei tu stesso a controllare l'ordine dei byte.

Ho riguardato il codice e qualcosa non torna devo rivedere un pò la logica della bufferizzazione dell'int

In pseudocodice :

lato client :

send(intero 32bit)

lato server :

ret=recv(&temp)

variabile lunghezza salvata nella struttura client
poi ad ogni recv farò una cosa del genere :

rimanenti=4-ret;
lunghezza | temp
if(ret != rimanenti) //non ho finito di ricevere 
client->lunghezza<<8*ret (shifto la lunghezza per metterla in posizione di aggiungerci i byte che verranno ricevuti al giro dopo)
if (ret==rimanenti)  
{
    client-> temp = 0; 
    client->rimanenti = 4;
    return;
}

Facendo così però mi va bene se il client invia il byte in questo modo:

parte più significativa
parte meno significativa

così il ricevitore riceverà prima la parte più significativa e poi la parte meno significativa.

Se lato sender invio in network byte order send(htonl(lunghezza)) quindi con la parte più significativa a destra dovrei ricevere lato ricevitore prima la parte più alta e poi quella più bassa giusto ?

[WarDuck]

Originariamente inviato da Daniels118

[..] immagina questa situazione con dei pacchetti da 512 byte:
1) invio un messaggio da 506 byte + 4 per la lunghezza, ma il pacchetto non parte perché il buffer ha ancora spazio per 2 byte e il sistema aspetta ancora un po' per vedere se si riempie;
2) subito dopo invio un messaggio di 100 byte + 4 per la lunghezza;
3) il sistema bufferizza i dati e li divide in due pacchetti, il primo contiene 4+506+2 byte, il secondo ne contiene 2+100;
4) il client riceve il primo pacchetto e ne legge 4 byte, vede che il dato è lungo 506 byte e li legge;
5) il buffer contiene ancora 2 byte, quindi il client prova a leggere 4 byte, ma ne ottiene solo due perché il secondo pacchetto non è ancora arrivato, quindi interpreta male la lunghezza del dato... da qui in poi si scatena l'inferno

Tu dici ho un pacchetto con: 4+506+2 bytes.

Leggo 4, capisco che devo leggere altri 506, leggo 506. Rimangono 2 bytes.

Quando chiedo 4 bytes, ovviamente mi devo assicurare che la recv legga 4 bytes, quindi il giusto modo di fare la cosa è fare la recv in un ciclo finché non leggo effettivamente il giusto numero di bytes.

Quello che dici non è un problema.

[aeroxr1]

Originariamente inviato da WarDuck

Tu dici ho un pacchetto con: 4+506+2 bytes.

Leggo 4, capisco che devo leggere altri 506, leggo 506. Rimangono 2 bytes.

Quando chiedo 4 bytes, ovviamente mi devo assicurare che la recv legga 4 bytes, quindi il giusto modo di fare la cosa è fare la recv in un ciclo finché non leggo effettivamente il giusto numero di bytes.

Quello che dici non è un problema.

si infatti lui mi ha consigliato di fare un ciclo per finire di leggere i byte rimanenti

Solo che il mio server deve essere monoprocesso monothread e devo usare la select , ma al tempo stesso non vorrei rimanere in loop per troppo tempo aspettando di aver ricevuto tutti i byte.

Per questo mi ha poi consigliato di gestire un buffer

Ora il buffer per la stringa dati mi sembra di averlo fatto e teoricamente mi sembra funzioni.

Il buffer per la ricezione dell'int della lunghezza del dato invcece mi crea non pochi problemi

EDIT [forse così potrebbe funzionare] :

int riceviLength() //usando lo shift sistemo i byte in host order senza usare la funzione ntohl 
{
   //in realtà inviando un int per la dimensione invio ben 4byte, devo gestire un buffer per la lunghezza
  int ret;
  int temp; //al suo interno ci viene salvato il dato letto
  ret = recvTCP(client->socket,&temp,4-client->last);
  client->length=(client->length)<<(8*(ret)); 
  client->length=(client->length)|temp;  
  
  if(ret<0) return -1; //c'è stata una chiusura della connessione già gestita dalla recvTCP o il dato è ricevuto correttamente
  if (ret==0)  //abbiamo finito di leggere
  {
  	client->last=0;
  	return 0;
  }
  client->last=client->last-ret;
  return ret;
}

ha qualche problemuccio questa funzione ?

Ah recvTCP mi ritorna 0 se ho letto tutto length , -1 se ci sono stati errori , ret se non abbiamo ancora finito di leggere.

[WarDuck]

Originariamente inviato da aeroxr1

si infatti lui mi ha consigliato di fare un ciclo per finire di leggere i byte rimanenti

Solo che il mio server deve essere monoprocesso monothread e devo usare la select , ma al tempo stesso non vorrei rimanere in loop per troppo tempo aspettando di aver ricevuto tutti i byte.

Questo è inevitabile, a meno di non usare socket non bloccanti.

Se ti aspetti di leggere 4 bytes, dovrai per forza aspettare che arrivino .

[aeroxr1]

Originariamente inviato da WarDuck

Questo è inevitabile, a meno di non usare socket non bloccanti.

Se ti aspetti di leggere 4 bytes, dovrai per forza aspettare che arrivino .

QUel problema l'ho risolto con gli stati

3 stati :
stato 0 -> attesa comando
stato 1 -> attesa lunghezza dati
stato 2 -> attesa dato

Ogni client ha una struttura e in essa è presente una variabile stato ultimo dato letto e un buffer, e da uno stato a l'altro ci va solo quando ha finito di fare la lettura. Così nel frattempo che il determinato socket non ha i dati disponibile la select riprende il controllo e può gestire le altre connessioni.

Mi manca di capire se ho gestito in maniera corretta i buffer. Che in locale è difficile capirlo

[aeroxr1]

ah scusate , ho una domandina nuova

Se mando una stringa avete detto non c'è problemi di endianess, come mai questa differenza di comportamento ?

e una domanda un pò off topic :

scanf vs fgets nella lettura dello stdin .

se leggo la stringa "pippo" e l'assegno alla variabile stringa usando scanf questa mi lascia \n in memoria e aggiunge l'eof a pippo e quindi in stringa ci sarà "pippo\0"
con fgets il buffer stdin mi viene completamente ripulito e viene assegnato a stringa "pippo\n\0" ? corretto ?
Quindi in una lettura di un un numero che poi dopo vado a convertire con strtol tutto ok perchè \n non me lo converte , ma se devo leggere una stringa è bene elimini l'ultimo carattere \n o sbaglio ? Come dovrei gestire questa situazione

[Daniels118]

Se mando una stringa avete detto non c'è problemi di endianess, come mai questa differenza di comportamento ?

Alcune famiglie di processori scambiano l'ordine dei byte quando li copiano tra memoria e registri. Ciò naturalmente vale solo quando si copiano 2 o più byte alla volta, e di conseguenza si applica alla maggior parte dei tipi di dato numerici ed anche alle stringhe con codifica multibyte.
Questa differenza di comportamento è nata diversi decenni fa, fondamentalmente per risparmiare sulla realizzazione dei circuiti (non so nello specifico in che modo), ed è stata ereditata dai processori più recenti per mantenere la retrocompatibilità.
Anche i compilatori possono impattare sull'endiannes quando lavorano con dati la cui dimensione supera quella dei registri, in questi casi infatti è il compilatore stesso a decidere l'ordine delle "parole" in memoria.

[aeroxr1]

ma quindi se invio la stringa

char pippo[10]={asino/0};

dall'altra parte, dato che invio 6 byte non è detto che arrivi la parola nell'ordine corretto ?

[Oceans11]

Originariamente inviato da aeroxr1

ma quindi se invio la stringa

char pippo[10]={asino/0};

dall'altra parte, dato che invio 6 byte non è detto che arrivi la parola nell'ordine corretto ?

No.
Come ti è stato detto,

si applica alla maggior parte dei tipi di dato numerici ed anche alle stringhe con codifica multibyte.

[Daniels118]

La risposta di Oceans11 è corretta.
Il motivo è che quando copi una stringa con codifica a byte singolo (per esempio ASCII), l'algoritmo copia i byte uno alla volta, nell'ordine in cui si trovano.
Se invece copi una stringa con codifica a 2 byte, l'algoritmo potrebbe copiare i byte due per volta (nel senso che fa un'unica MOVE a 16 bit); l'ordine delle lettere resta invariato, ma l'ordine dei byte di ciascuna lettera potrebbe essere invertito o meno in base all'endiannes.
Se hai intenzione di utilizzare codifiche multibyte devi tener conto anche di questo aspetto, altrimenti puoi semplicemente ignorarlo.

[aeroxr1]

Originariamente inviato da Daniels118

La risposta di Oceans11 è corretta.
Il motivo è che quando copi una stringa con codifica a byte singolo (per esempio ASCII), l'algoritmo copia i byte uno alla volta, nell'ordine in cui si trovano.
Se invece copi una stringa con codifica a 2 byte, l'algoritmo potrebbe copiare i byte due per volta (nel senso che fa un'unica MOVE a 16 bit); l'ordine delle lettere resta invariato, ma l'ordine dei byte di ciascuna lettera potrebbe essere invertito o meno in base all'endiannes.
Se hai intenzione di utilizzare codifiche multibyte devi tener conto anche di questo aspetto, altrimenti puoi semplicemente ignorarlo.

scusate ho domandato senza nemmeno essere sicuro di aver capito completamente la risposta , avevo confuso la "codifica multibyte" con una stringa di più byte

Grazie a tutti

[aeroxr1]

Ho un grosso problema , ma non sapendo bene fare ad usare il debug è difficile che riuscirò a risolverlo

Non capisco come , ma nonostante elimini un elemento dalla lista dei client al passo dopo mi continua a dire che quell'elemento è ancora presente .. boh...

Ho trovato dove è l'errore, ma non capisco come mai....
Qualche anima pia , ha due secondi per dare un occhiata al file ?

Ecco di seguito :

struct elemento 
{ 
	char username[256]; //Username del giocatore [max 14 caratteri]
	short int UDPport;
	unsigned long IPaddress;
	int socket; //id del socket
	char ready; //indica se il client ha effettuato il login o è sempre in attesa di login e quindi non ancora connesso
	char impegnato; //mi indicherà Se il client è impegnato in un'altra partita
	char cmd ; //il comando che stiamo eseguendo. Inizialmente in waiting !
	int stato; //variabile di stato che mi dice in che parte della macchina a stati si trova il client
	int length; //lunghezza campo dati
	char buffer[256]; //buffer dove vengono ricevuti i dati temporaneamente prima di essere ricevuti completamente, buffer dinamico
	int last; //variabile che indica fino a che punto abbiamo riempito il buffer in caso di lettura non terminata
	struct elemento *next; //puntatore all'elemento successivo della lista
	struct elemento *enemy; //puntatore alla struttura dell'avversario
};

typedef struct elemento player;

di seguito la funzione che uso per creare un elemento player :

player *creatElem(int socket,unsigned long IPaddress)
{
  player *elem = NULL;
  elem = malloc(sizeof(player));
  elem->IPaddress = IPaddress;
  elem->socket = socket;
  elem->ready = NO; //inizialmente si crea l'elemento ma non è realmente connesso ! 
  elem->impegnato = NO;
  elem->next = NULL;
  elem->enemy = NULL;  //puntatore al socket dell'avversario
  elem->stato = 0;
  elem->last=0;
  memset(elem->username,0,sizeof(elem->username));
  memset(elem->buffer,0,sizeof(elem->buffer));
  return elem;  //ritorno l'elemento creato
}

// PARTE DEL MAIN CHE MI CREA PROBLEMI

for(i=0;i<=fdmax;i++)
		{
			if(FD_ISSET(i,&read_fds)){ //controlla se un descrittore è settato
		 		if (i==listener) // se è il listener vuol dire che c'è una nuova connessione in sospeso 
		 		{	
		 		    //gestisco la nuova connessione
		 			addrlen = sizeof(clientaddr);
		 			newfd=accept(listener,(struct sockaddr*)&clientaddr,&addrlen);
		 			if(newfd==-1)
		 			{
		 				perror("errore nell'accept");
		 				exit(1);
		 			}
		 			printf("connessione stabilita con il client\n");
		 			FD_SET(newfd,&master); //setto il descrittore del socket appena connesso nel master
		 			if (newfd>fdmax) fdmax=newfd; //fdmax segnala quale è il più alto descrittore
					//creo un elemento del tipo Player socket newfd e ind IPaddress e lo inserisco nella lista ""inconnection"
		 			client=creatElem(newfd,clientaddr.sin_addr.s_addr);
		 			addToList(client); 
		 			printf("Il nuovo elemento puntato è : %s \n",client->username);
		 		}
		 		else
		 		{
		 			// gestisco dei dati provenienti da uno dei client che sono o nella lista connessi
		 			client=elem_findbysock(i); 
		 			if (client==NULL)
		 			{
		 				printf("il client non esiste, deve esserci stato un errore\n");
		 				exit(1);
		 			}
		 			//è stato trovato un client, verifichiamo in che stato si trova tale client
		 			
		 		......................

se levo la parte in neretto , nella parte in rosso nonostante crei un nuovo elemento con la malloc rimane comunque il dato inserito da un utente che è stato rimosso precedentemente.

Come è possibile ? Dove ho sbagliato ??

[aeroxr1]

Allora ho deciso passo alla codifica del numero in un char da 4byte con sprintf come mi ha consigliato @Daniels118

(con la shift non sono sicuro sia riuscito ad implementarla nel modo corretto)

Quindi farò così :

Originariamente inviato da Daniels118

Nulla di più vero di quanto dice Oceans11.
Suggerirei di convertire il numero che rappresenta la lunghezza del dato in una stringa di lunghezza fissa, per esempio int 5 diventa char[4] "0005", in questo modo la lettura diventa più semplice (leggi sempre 4 byte fissi) e risolvi il problema dell'endianess.

In realtà leggo sempre 5byte non 4byte inviando una stringa di 4 giusto ? sarebbe tipo 0005\0 o sbaglio ?

Originariamente inviato da Daniels118

Ricordati che la recv non ritorna il dato letto, ma devi passare in input un puntatore ad un buffer. Io personalmente farei così:

char buf[4];
int n = 0;
while (n < 4) {
  n += recv(sockfd, &buf[n], 4 - n, 0);
}

mettendo un bel buf[5] e il ciclo n<5 , no ?

p.s : in effetti potrei anche evitare di ricevere \0 , però mi potrebbe tornare utile quando chiamerò la funzione di conversione da stringa ad intero