[C++] ancora problemi con le socket

[misterx]

problema risolto, il segreto era proprio tale linea

while((ByteRicevuti=Socket->ReceiveBuf(Buf, Size)) > 0);

se dovesse servire a qualcuno

void __fastcall TForm1::ServerSocket1ClientRead(TObject *Sender,
      TCustomWinSocket *Socket)
{
  char *Buf;
  String Buffer;
  int  Size;
  int ByteRecived;
  int mioheader=0, mioend=0;

  Size = Socket->ReceiveLength();

// inizio a costruire il mio buffer
  if(Size > 0)
   {
         Buf = new char[Size];
         while( (ByteRecived=Socket->ReceiveBuf(buffer, Size)) > 0 )
        {
           if( strstr(Buf.c_str(), "INIZIODATI," ) mioheader++
           if( strstr(Buf.c_str(), "FINEDATI," ) mioend++
           Buffer+=Buf;
        }
   }

   if( mioheader == 1 && mioend == 1  ) 
   {
	MiaFunzione();
             Buffer="";
   }


}

[misterx]

ciao,
avrò letto quasi tutta la rete ma ancora non sono soddisfatto in quanto mi rimangono sempre dei dubbi che non mi permettono di capire sino in fondo se quello che sto facendo ha un senso.

In Borland Builder quando si decide di scrivere un applicativo server, il programmatore ha a disposizione una ricca serie di componenti i quali posseggono metodi (funzioni), proprietà ed eventi.
Una volta implementato un piccolo server, ad esempio, si ha a disposizione l'evento

void __fastcall TForm1::ServerSocket1ClientRead(TObject *Sender,
TCustomWinSocket *Socket)
{
}

che ho già mostrato in altri 3D di cui però non è chiarissimo quante volte viene scatenato.
Supponiamo che un client si connette al server e vuole inviare 1 file da 1 MB; se non erro la dimensione massima di un pacchetto TCP/IP è di 8192 byte quindi, il client deve inviare al server 1048576:8192=128 pacchetti sempre che si abbia la fortuna che i pacchetti siano tutti da 8192 byte.
Se qualcuno che ha avuto a che fare con Borland Builder mi sa dire se l'evento citato sopra viene generato 128 mi farebbe un grandissimo favore. Ho provato ad inserire in quell'evento una variabile contatrice, globale, ed ho notato che inviando un file da qualche centinaio di KB si direbbe che viene generato parecchie volte e si direbbe, tante quanti sono i pacchetti ricevuti dal server: ma è così o c'è dell'altro che non riesco a scovare da nessuna parte?


grazie 1000

[WarDuck]

Originariamente inviato da misterx

ciao,
avrò letto quasi tutta la rete ma ancora non sono soddisfatto in quanto mi rimangono sempre dei dubbi che non mi permettono di capire sino in fondo se quello che sto facendo ha un senso.

In Borland Builder quando si decide di scrivere un applicativo server, il programmatore ha a disposizione una ricca serie di componenti i quali posseggono metodi (funzioni), proprietà ed eventi.
Una volta implementato un piccolo server, ad esempio, si ha a disposizione l'evento

void __fastcall TForm1::ServerSocket1ClientRead(TObject *Sender,
TCustomWinSocket *Socket)
{
}

che ho già mostrato in altri 3D di cui però non è chiarissimo quante volte viene scatenato.
Supponiamo che un client si connette al server e vuole inviare 1 file da 1 MB; se non erro la dimensione massima di un pacchetto TCP/IP è di 8192 byte quindi, il client deve inviare al server 1048576:8192=128 pacchetti sempre che si abbia la fortuna che i pacchetti siano tutti da 8192 byte.
Se qualcuno che ha avuto a che fare con Borland Builder mi sa dire se l'evento citato sopra viene generato 128 mi farebbe un grandissimo favore. Ho provato ad inserire in quell'evento una variabile contatrice, globale, ed ho notato che inviando un file da qualche centinaio di KB si direbbe che viene generato parecchie volte e si direbbe, tante quanti sono i pacchetti ricevuti dal server: ma è così o c'è dell'altro che non riesco a scovare da nessuna parte?


grazie 1000

Dipende dal frame ethernet e dall'MTU dei router.

Tipicamente Ethernet standard può arrivare fino a 1514 bytes ( con i Jumbo Frame si arriva circa ai 9KB se non erro e con i Super Jambo Frame a 64K).

Tolti i 14 bytes per l'header di Ethernet, rimangono 1500 bytes per IP, ed è tipicamente l'MTU che utilizzano i router.

Leva altri 40 bytes di header di IP e TCP e arrivi a 1460 bytes di dati utili.

Questo significa che nel tuo esempio il trasferimento di un file da 1MB richiederebbe:

1048576/1460 = 719 pacchetti circa

Nota bene: se decidi di leggere da una socket 4K alla volta, i meccanismi di buffering del sistema operativo potrebbero far abbassare il numero di system call necessarie.

Il punto è che stai usando un'api di cui se non ho capito male non si conoscono i dettagli implementativi.

[misterx]

Originariamente inviato da WarDuck

Il punto è che stai usando un'api di cui se non ho capito male non si conoscono i dettagli implementativi.

è esattamente così. Mi sto ostinando ad usare tale componente già pronto solo perchè, essendo il mio progetto piuttosto complesso, tale componente è gia testato e mi fa comodo evitare problemi che di sicuro già esistono da qualche parte.
Per conoscenza, 8192 sono i byte che mi indica il compilatore quando chiamo la Size = Socket->ReceiveLength(); e quando invio da un client pacchetti di una certa dimensione cioè: il mio client casareccio legge da disco attraverso una fgets() ed ogni linea letta viene bufferizzata formando un bufferone che solo alla fine passa alla SendBuf() la quale crea pacchetti da 8192 byte.

[ESSE-EFFE]

Originariamente inviato da WarDuck

Il punto è che stai usando un'api di cui se non ho capito male non si conoscono i dettagli implementativi.

A dire il vero tra documentazione ufficiale (http://docs.embarcadero.com/products/rad_studio/), libri, portali dedicati, forum, newsgroup e sorgenti VCL di informazioni se ne trovano a quintali.

[misterx]

Originariamente inviato da ESSE-EFFE

A dire il vero tra documentazione ufficiale (http://docs.embarcadero.com/products/rad_studio/), libri, portali dedicati, forum, newsgroup e sorgenti VCL di informazioni se ne trovano a quintali.

se mi dici dove spiega quanto chiedo mi faresti un grandissimo favore, io non trovo nulla.

p.s.
questa ti sembra una spiegazione?

http://docwiki.embarcadero.com/Libra....ReceiveLength

[WarDuck]

Io consiglierei di partire da qua:

http://docwiki.embarcadero.com/Libra...inSocketStream

Originariamente inviato da misterx

se mi dici dove spiega quanto chiedo mi faresti un grandissimo favore, io non trovo nulla.

p.s.
questa ti sembra una spiegazione?

http://docwiki.embarcadero.com/Libra....ReceiveLength

Call ReceiveLength to determine the amount of information to read over the socket connection in response to an asynchronous read notification.

Note: ReceiveLength is not guaranteed to be accurate for streaming socket connections.

[misterx]

Originariamente inviato da WarDuck

Io consiglierei di partire da qua:

http://docwiki.embarcadero.com/Libra...inSocketStream




Call ReceiveLength to determine the amount of information to read over the socket connection in response to an asynchronous read notification.

Note: ReceiveLength is not guaranteed to be accurate for streaming socket connections.

letto grazie 1000, lo trovo però molto lacunoso; molte delle cose che osservo sperimentando non vengono minimamente spiegate e ti vedi costretto a fare miriadi di esperimenti, non che ciò mi turbi però vorrei ottenere alla fine un qualcosa di affidabile che riesco a controllare e non un qualcosa che funzionicchia chissà perchè
Andrà a finire che seguirò alla lettera il tuo consiglio, spostarmi sulle care e vecchi windows API, almeno vedi ciò che accade.

Cerca cerca ho trovato la guida Borland Builder per windows dove si dice che usare le socket in questo ambiente è banale, basta trascinare e settare qualche proprietà e tutto il resto è magia, mah

Se arrivo da qualche parte faccio sapere, almeno il prossimo non diventa matto come lo sto diventando io e ci scommetto che sono vittima di una banalità

grazie ancora per i link

[misterx]

trovandomi a lavorare col mio programma a livello applicativo, sotto ho TCP(IP che mi da le dovute garanzie, esiste una casistica che spiega a cosa possono essere dovuti eventuali perdite di pacchetti a livello applicativo?

Ho notato che nel piccolo client che ho scritto se aggiungo un ritardo di 20 ms nell'inoltro di pacchetti non ho perdite, però questo è un modo non corretto di operare in quanto mi baso sulla probabilità/fortuna che tutti i pacchetti arrivano entro 20 ms. Se dovessi avere un ritardo maggiore per una qualche ragione addio

[misterx]

edit