Torna indietro   Hardware Upgrade Forum > Software > Programmazione

Lenovo Legion Go 2: Ryzen Z2 Extreme e OLED 8,8'' per spingere gli handheld gaming PC al massimo
Lenovo Legion Go 2: Ryzen Z2 Extreme e OLED 8,8'' per spingere gli handheld gaming PC al massimo
Lenovo Legion Go 2 è la nuova handheld PC gaming con processore AMD Ryzen Z2 Extreme (8 core Zen 5/5c, GPU RDNA 3.5 16 CU) e schermo OLED 8,8" 1920x1200 144Hz. È dotata anche di controller rimovibili TrueStrike con joystick Hall effect e una batteria da 74Wh. Rispetto al dispositivo che l'ha preceduta, migliora ergonomia e prestazioni a basse risoluzioni, ma pesa 920g e costa 1.299€ nella configurazione con 32GB RAM/1TB SSD e Z2 Extreme
AWS re:Invent 2025: inizia l'era dell'AI-as-a-Service con al centro gli agenti
AWS re:Invent 2025: inizia l'era dell'AI-as-a-Service con al centro gli agenti
A re:Invent 2025, AWS mostra un’evoluzione profonda della propria strategia: l’IA diventa una piattaforma di servizi sempre più pronta all’uso, con agenti e modelli preconfigurati che accelerano lo sviluppo, mentre il cloud resta la base imprescindibile per governare dati, complessità e lock-in in uno scenario sempre più orientato all’hybrid cloud
Cos'è la bolla dell'IA e perché se ne parla
Cos'è la bolla dell'IA e perché se ne parla
Si parla molto ultimamente di "bolla dell'intelligenza artificiale", ma non è sempre chiaro perché: l'IA è una tecnologia molto promettente e che ha già cambiato molte cose dentro e fuori le aziende, ma ci sono enormi aspettative che stanno gonfiando a dismisura i valori delle azioni e distorcendo il mercato. Il che, com'è facile intuire, può portare a una ripetizione della "bolla dotcom", e forse anche di quella dei mutui subprime. Vediamo perché
Tutti gli articoli Tutte le news

Vai al Forum
Rispondi
 
Strumenti
Old 20-06-2012, 21:05   #1
misterx
Senior Member
 
Iscritto dal: Apr 2001
Città: Milano
Messaggi: 3739
[C++] Socket con Borland Builder C++

ciao,
ho preso in prestito questa porzione di codice in stile Borland Builder C++ il quale una volta inserito nell'evento approriato, prende tutto, nel mio caso mi interessa testo in formato ASCII, che viene inviato da un client e lo visualizza nel componente Memo dell'aplicativo server.

Problema: inviando n volte il medesimo file, a volte viene troncato in coda ed a volte manca la testa del file; altre ancora vengono prelevati solo 2 o più caratteri. Avete conoscenza di questo funzionamento randomico della VCL?

p.s.
anche terminando Buffer a NULL il risultato è il medesimo.

note: la mia convinzione è che il protocollo TCP/IP dovrebbe garantirmi la ritrasmissione nel caso di perdita di pacchetti.

grazie

Codice:
 int Size=ClientSocket1->Socket->ReceiveLength();
 char *Buffer = new char[Size];
 ClientSocket1->Socket->ReceiveBuf(Buffer,Size);
 Memo1->Lines->Add(Buffer);
http://forum.html.it/forum/showthrea...hreadid=610596
misterx è offline   Rispondi citando il messaggio o parte di esso
Old 21-06-2012, 06:56   #2
karch_kiraly
Member
 
Iscritto dal: Nov 2005
Messaggi: 96
Non conosco il Borland builder c++. Per certo utilizzando il protocollo TCP hai la garanzia di ricezione dei dati trasmessi (a differenza dell'UDP).
karch_kiraly è offline   Rispondi citando il messaggio o parte di esso
Old 21-06-2012, 08:06   #3
misterx
Senior Member
 
Iscritto dal: Apr 2001
Città: Milano
Messaggi: 3739
Quote:
Originariamente inviato da karch_kiraly Guarda i messaggi
Non conosco il Borland builder c++. Per certo utilizzando il protocollo TCP hai la garanzia di ricezione dei dati trasmessi (a differenza dell'UDP).
grazie per la conferma, difatti era quello che mi ricordavo
misterx è offline   Rispondi citando il messaggio o parte di esso
Old 21-06-2012, 08:48   #4
misterx
Senior Member
 
Iscritto dal: Apr 2001
Città: Milano
Messaggi: 3739
scusate ma mi viene un dubbio se sia legale o meno inviare dati ad un server in questo modo:

Codice:
while ( fgets(linea,sizeof(linea),fp) != NULL)
                {
                if( ClientSocket1->Active )
                        ClientSocket1->Socket->SendBuf(linea,strlen(linea));
                }
cioè una linea alla volta presa da disco.
Non credo che si debba creare preventivamente, allocandolo, un buffer gigantesco per poi inviarlo vero?
misterx è offline   Rispondi citando il messaggio o parte di esso
Old 21-06-2012, 14:21   #5
lorenzo001
Senior Member
 
Iscritto dal: Jul 2008
Città: Roma
Messaggi: 542
Puoi inviare i dati come vuoi. Però, dalla parte di chi riceve, come si fa a determinare quanti caratteri ricevuti fanno parte della stringa?
lorenzo001 è offline   Rispondi citando il messaggio o parte di esso
Old 21-06-2012, 19:18   #6
misterx
Senior Member
 
Iscritto dal: Apr 2001
Città: Milano
Messaggi: 3739
Quote:
Originariamente inviato da lorenzo001 Guarda i messaggi
Puoi inviare i dati come vuoi. Però, dalla parte di chi riceve, come si fa a determinare quanti caratteri ricevuti fanno parte della stringa?
se ho capito la tua domanda, ci pensa la chiamata:
int size=ServerSocket1->Socket->ReceiveLength();

unico dubbio è che non so se la dimensione ritornata si riferisce ad un pacchetto (porzione del file inviato dal client) oppure alla dimensione totale del file che verrà inviato da un client.

Facendo delle prove per uno stesso file ho notato che ogni volta size è differente; a volte ha la dimensione dell'intero file, a volte solo pochi caratteri.

Se la size si riferisce al payload di un solo pacchetto allora avrei scoperto dove sta l'erore, in caso contrario allora c'è un problema nelle socket ma ho qualche dubbio.
misterx è offline   Rispondi citando il messaggio o parte di esso
Old 21-06-2012, 20:23   #7
ESSE-EFFE
Member
 
Iscritto dal: May 2009
Messaggi: 186
Quote:
Originariamente inviato da misterx Guarda i messaggi
scusate ma mi viene un dubbio se sia legale o meno inviare dati ad un server in questo modo:

Codice:
while ( fgets(linea,sizeof(linea),fp) != NULL)
                {
                if( ClientSocket1->Active )
                        ClientSocket1->Socket->SendBuf(linea,strlen(linea));
                }
cioè una linea alla volta presa da disco.
Non credo che si debba creare preventivamente, allocandolo, un buffer gigantesco per poi inviarlo vero?
Ammesso che non ci siano inghippi a leggere il file in quel modo, vedo due problemi: il primo è che la SendBuf potrebbe sollevare un'eccezione (che dal codice non sembra gestita). Il secondo è che bisognerebbe verificare il valore di ritorno della SendBuf, per controllare che il buffer sia stato effettivamente trasmesso (accodato) altrimenti va gestito opportunamente l'errore.

Inoltre, quell'if all'interno del ciclo penso sia inutile.
__________________
ESSE-EFFE.com
Sviluppo software e Web
Creazione loghi - Bergamo
ESSE-EFFE è offline   Rispondi citando il messaggio o parte di esso
Old 21-06-2012, 20:31   #8
ESSE-EFFE
Member
 
Iscritto dal: May 2009
Messaggi: 186
Quote:
Originariamente inviato da misterx Guarda i messaggi
se ho capito la tua domanda, ci pensa la chiamata:
int size=ServerSocket1->Socket->ReceiveLength();

unico dubbio è che non so se la dimensione ritornata si riferisce ad un pacchetto (porzione del file inviato dal client) oppure alla dimensione totale del file che verrà inviato da un client.

Facendo delle prove per uno stesso file ho notato che ogni volta size è differente; a volte ha la dimensione dell'intero file, a volte solo pochi caratteri.

Se la size si riferisce al payload di un solo pacchetto allora avrei scoperto dove sta l'erore, in caso contrario allora c'è un problema nelle socket ma ho qualche dubbio.
Non c'è nessun problema nei socket. Quella dimensione ovviamente è pari alla quantità dei byte a disposizione (da leggere). Non è detto (ed è improbabile) che coincida con quella del pacchetto inviato lato client. Ancora più improbabile che coincida con la dimensione del file (salvo casi particolari).
__________________
ESSE-EFFE.com
Sviluppo software e Web
Creazione loghi - Bergamo
ESSE-EFFE è offline   Rispondi citando il messaggio o parte di esso
Old 21-06-2012, 21:19   #9
misterx
Senior Member
 
Iscritto dal: Apr 2001
Città: Milano
Messaggi: 3739
Quote:
Originariamente inviato da ESSE-EFFE Guarda i messaggi
Non c'è nessun problema nei socket. Quella dimensione ovviamente è pari alla quantità dei byte a disposizione (da leggere). Non è detto (ed è improbabile) che coincida con quella del pacchetto inviato lato client. Ancora più improbabile che coincida con la dimensione del file (salvo casi particolari).
vuoi dire che per ricevere il file completo mi servono n chiamate a quella funzione?

Se è così allora il mio problema è di concetto e del tipo:
Codice:
FILE *fp;
fp=fopen("prova.txt","w");
int size=ServerSocket1->Socket->ReceiveLength();
char *Buffer = new char[Size];
ServerSocket1->Socket->ReceiveBuf(Buffer,Size);
fprintf(fp,"%s",Buffer);
fclose(fp);
tralasciando le inesattezze del codice, sto pretendendo in quel modo di salvare tutto il file inviato dal client con un'unica chiamata a ReceiveBuf()?

Spero si capisca la mia affermazione.
misterx è offline   Rispondi citando il messaggio o parte di esso
Old 22-06-2012, 08:45   #10
ESSE-EFFE
Member
 
Iscritto dal: May 2009
Messaggi: 186
Quote:
Originariamente inviato da misterx Guarda i messaggi
vuoi dire che per ricevere il file completo mi servono n chiamate a quella funzione?

Se è così allora il mio problema è di concetto e del tipo:
Codice:
FILE *fp;
fp=fopen("prova.txt","w");
int size=ServerSocket1->Socket->ReceiveLength();
char *Buffer = new char[Size];
ServerSocket1->Socket->ReceiveBuf(Buffer,Size);
fprintf(fp,"%s",Buffer);
fclose(fp);
tralasciando le inesattezze del codice, sto pretendendo in quel modo di salvare tutto il file inviato dal client con un'unica chiamata a ReceiveBuf()?

Spero si capisca la mia affermazione.
Esatto, per ricevere tutto il file è verosimile che ti servano diverse chiamate alla ReceiveBuf (o ReceiveText). Non puoi farlo con una chiamata unica perchè non funzionerà praticamente mai. Il TCP è un protocollo di trasporto, ma poi è necessario stabilire un protocollo a livello applicativo per far dialogare le parti (client e server).
__________________
ESSE-EFFE.com
Sviluppo software e Web
Creazione loghi - Bergamo
ESSE-EFFE è offline   Rispondi citando il messaggio o parte di esso
Old 24-06-2012, 20:09   #11
misterx
Senior Member
 
Iscritto dal: Apr 2001
Città: Milano
Messaggi: 3739
Quote:
Originariamente inviato da ESSE-EFFE Guarda i messaggi
Esatto, per ricevere tutto il file è verosimile che ti servano diverse chiamate alla ReceiveBuf (o ReceiveText). Non puoi farlo con una chiamata unica perchè non funzionerà praticamente mai. Il TCP è un protocollo di trasporto, ma poi è necessario stabilire un protocollo a livello applicativo per far dialogare le parti (client e server).
ecco perchè facendo n invii il server a volte, il server, riceveva il file completo ed a volte no. Difatto studiano la dimensione del buffer ricevuto dal server questo cambiava randomicamente ogni vota.
Quindi una sorta di carattere o simbolo inviato dal client allo scopo di informare il server della testa e coda del file dovrebbe funzionare vero?

Lato server continui a leggere sino a quando ricevi il carattere speciale di fine file.

Non so se solitamente si segue questa strada, magari c'è un modo più furbo?
misterx è offline   Rispondi citando il messaggio o parte di esso
Old 25-06-2012, 14:38   #12
ESSE-EFFE
Member
 
Iscritto dal: May 2009
Messaggi: 186
Quote:
Originariamente inviato da misterx Guarda i messaggi
Quindi una sorta di carattere o simbolo inviato dal client allo scopo di informare il server della testa e coda del file dovrebbe funzionare vero?

Lato server continui a leggere sino a quando ricevi il carattere speciale di fine file.

Non so se solitamente si segue questa strada, magari c'è un modo più furbo?
E' una soluzione semplice che può funzionare. Basta che i sincronismi non siano presenti nel file ovviamente.

Altra soluzione comune è quella di inviare un header in cui sia presente la dimensione del file (o comunque dei dati) da inviare. Così facendo si potrebbero trasferire anche altre informazioni, come ad esempio il nome del file.

Oppure si utilizzano protocolli standard più complessi come HTTP o FTP.
__________________
ESSE-EFFE.com
Sviluppo software e Web
Creazione loghi - Bergamo
ESSE-EFFE è offline   Rispondi citando il messaggio o parte di esso
Old 25-06-2012, 14:59   #13
misterx
Senior Member
 
Iscritto dal: Apr 2001
Città: Milano
Messaggi: 3739
Quote:
Originariamente inviato da ESSE-EFFE Guarda i messaggi
E' una soluzione semplice che può funzionare. Basta che i sincronismi non siano presenti nel file ovviamente.

Altra soluzione comune è quella di inviare un header in cui sia presente la dimensione del file (o comunque dei dati) da inviare. Così facendo si potrebbero trasferire anche altre informazioni, come ad esempio il nome del file.

Oppure si utilizzano protocolli standard più complessi come HTTP o FTP.
nel frattempo sto provando ad usare un sistema con due buffer: uno che viene definito ogni volta ed uno dinamico, questo per usare il metodo dell'informazione in testa ed in coda al file.

Un dubbio che ho è come mai se invio prima l'informazione che stabilisce l'inizio del file e poi il corpo ed infine la coda, a volte nella medesima chiamata a ServerSocket1->Socket->ReceiveBuf(Buffer,Size); trovo l'informazione di testa ed il corpo inzieme.

Per farmi capire, si comporta come il buffer di una stampante dove s e non vi sono sufficienti caratteri questa non stampa.

Quello che vorrei ottenere è l'invio della testa del file, del corpo ed infine della coda ed almeno che testa e coda vengano inviati non assieme al corpo: è possibile?
misterx è offline   Rispondi citando il messaggio o parte di esso
Old 25-06-2012, 15:18   #14
misterx
Senior Member
 
Iscritto dal: Apr 2001
Città: Milano
Messaggi: 3739
Quote:
Originariamente inviato da ESSE-EFFE Guarda i messaggi
Basta che i sincronismi non siano presenti nel file ovviamente.
dimenticavo: cosa intendi con quella frase?
misterx è offline   Rispondi citando il messaggio o parte di esso
Old 25-06-2012, 15:23   #15
ESSE-EFFE
Member
 
Iscritto dal: May 2009
Messaggi: 186
Quote:
Originariamente inviato da misterx Guarda i messaggi
Un dubbio che ho è come mai se invio prima l'informazione che stabilisce l'inizio del file e poi il corpo ed infine la coda, a volte nella medesima chiamata a ServerSocket1->Socket->ReceiveBuf(Buffer,Size); trovo l'informazione di testa ed il corpo inzieme.
Evidentemente a livello TCP le due informazioni sono state inviate in un unico pacchetto. Considerando che probabilmente quella che tu chiami "informazione di testa" sarà un byte solo, la cosa è abbastanza logica.

In genere, non si controlla come vengono spediti i byte. Sarebbe una complicazione in più senza alcun vantaggio.
__________________
ESSE-EFFE.com
Sviluppo software e Web
Creazione loghi - Bergamo
ESSE-EFFE è offline   Rispondi citando il messaggio o parte di esso
Old 25-06-2012, 15:30   #16
ESSE-EFFE
Member
 
Iscritto dal: May 2009
Messaggi: 186
Quote:
Originariamente inviato da misterx Guarda i messaggi
dimenticavo: cosa intendi con quella frase?
Intendo che i byte utilizzati come sincronismo non devono essere presenti nei dati, altrimenti chi riceve non riuscirebbe a riconoscerli. Quindi, per file di testo problemi non ce ne sono, ma per inviare qualunque tipo di file, utilizza un header.
__________________
ESSE-EFFE.com
Sviluppo software e Web
Creazione loghi - Bergamo
ESSE-EFFE è offline   Rispondi citando il messaggio o parte di esso
Old 25-06-2012, 15:39   #17
misterx
Senior Member
 
Iscritto dal: Apr 2001
Città: Milano
Messaggi: 3739
Quote:
Originariamente inviato da ESSE-EFFE Guarda i messaggi
Considerando che probabilmente quella che tu chiami "informazione di testa" sarà un byte solo, la cosa è abbastanza logica.
perchè parli di un byte?
Io sto usando una intesazione del tipo <INIZIOFILE>, ............ , <FINEFILE> è concettualmente sbagliato?
misterx è offline   Rispondi citando il messaggio o parte di esso
Old 25-06-2012, 15:47   #18
ESSE-EFFE
Member
 
Iscritto dal: May 2009
Messaggi: 186
Quote:
Originariamente inviato da misterx Guarda i messaggi
perchè parli di un byte?
Io sto usando una intesazione del tipo <INIZIOFILE>, ............ , <FINEFILE>
Perchè sarebbe sufficiente un byte. Ma per il discorso del pacchetto TCP è la stessa cosa. Idem per l'eventuale presenza delle intestazioni all'interno del file.
__________________
ESSE-EFFE.com
Sviluppo software e Web
Creazione loghi - Bergamo
ESSE-EFFE è offline   Rispondi citando il messaggio o parte di esso
Old 25-06-2012, 15:59   #19
misterx
Senior Member
 
Iscritto dal: Apr 2001
Città: Milano
Messaggi: 3739
Quote:
Originariamente inviato da ESSE-EFFE Guarda i messaggi
Perchè sarebbe sufficiente un byte. Ma per il discorso del pacchetto TCP è la stessa cosa. Idem per l'eventuale presenza delle intestazioni all'interno del file.
scusa ma non potrebbe accadere che il byte da te scelto viene confuso con un byte del testo che vuoi ricevere/inviare?
misterx è offline   Rispondi citando il messaggio o parte di esso
Old 25-06-2012, 17:06   #20
ESSE-EFFE
Member
 
Iscritto dal: May 2009
Messaggi: 186
Quote:
Originariamente inviato da misterx Guarda i messaggi
scusa ma non potrebbe accadere che il byte da te scelto viene confuso con un byte del testo che vuoi ricevere/inviare?
Vedi messaggi precedenti:

Quote:
Originariamente inviato da ESSE-EFFE Guarda i messaggi
Basta che i sincronismi non siano presenti nel file ovviamente.
Quote:
Originariamente inviato da ESSE-EFFE Guarda i messaggi
Intendo che i byte utilizzati come sincronismo non devono essere presenti nei dati, altrimenti chi riceve non riuscirebbe a riconoscerli. Quindi, per file di testo problemi non ce ne sono, ma per inviare qualunque tipo di file, utilizza un header.
__________________
ESSE-EFFE.com
Sviluppo software e Web
Creazione loghi - Bergamo
ESSE-EFFE è offline   Rispondi citando il messaggio o parte di esso
 Rispondi


Lenovo Legion Go 2: Ryzen Z2 Extreme e OLED 8,8'' per spingere gli handheld gaming PC al massimo Lenovo Legion Go 2: Ryzen Z2 Extreme e OLED 8,8'...
AWS re:Invent 2025: inizia l'era dell'AI-as-a-Service con al centro gli agenti AWS re:Invent 2025: inizia l'era dell'AI-as-a-Se...
Cos'è la bolla dell'IA e perché se ne parla Cos'è la bolla dell'IA e perché se...
BOOX Palma 2 Pro in prova: l'e-reader diventa a colori, e davvero tascabile BOOX Palma 2 Pro in prova: l'e-reader diventa a ...
FRITZ!Repeater 1700 estende la rete super-veloce Wi-Fi 7 FRITZ!Repeater 1700 estende la rete super-veloce...
Cloud sovrano: l'approccio di Broadcom c...
HONOR conferma l'arrivo in Italia di Mag...
La Cina sotto pressione impone maniglie ...
OpenAI integra le app in ChatGPT per tra...
NVIDIA sarebbe pronta a tagliare la prod...
Prezzo minimo storico per iPhone 16 Pro:...
Riot Games scopre una falla nei BIOS che...
Beats in super offerta su Amazon: aurico...
Batterie elettriche, Samsung SDI e Stell...
Clivet presenta Fullness, la pompa di ca...
SpaceX lancerà 167 razzi spaziali...
Yakuza Kiwami 3 e Dark Ties protagonisti...
Privacy a rischio: ecco la VPN che regis...
SpaceX ha annunciato che un satellite St...
ASUSTOR presenta i nuovi NAS Lockerstor ...
Chromium
GPU-Z
OCCT
LibreOffice Portable
Opera One Portable
Opera One 106
CCleaner Portable
CCleaner Standard
Cpu-Z
Driver NVIDIA GeForce 546.65 WHQL
SmartFTP
Trillian
Google Chrome Portable
Google Chrome 120
VirtualBox
Tutti gli articoli Tutte le news Tutti i download

Strumenti

Regole
Non Puoi aprire nuove discussioni
Non Puoi rispondere ai messaggi
Non Puoi allegare file
Non Puoi modificare i tuoi messaggi

Il codice vB è On
Le Faccine sono On
Il codice [IMG] è On
Il codice HTML è Off
Vai al Forum


Tutti gli orari sono GMT +1. Ora sono le: 18:03.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Served by www3v