gmxsm (Normal User)
Newbie
Messaggi: 20
Iscritto: 06/12/2007
|
Salve a tutti,
è da un bel po di tempo che visito questo sito ed in particolare la sezione del forum su VB, cercando di "captare" quando più possibile dai vari post..
Da ieri però ho cominciato a sbattere la testa contro uno dei 4 muri di casa e, prima di abbaterlo ed essere quindi sbattuto fuori casa dai miei  , ho deciso di chiedere aiuto a chi più di me ne sa..
Il problema che mi sono trovato davanti è il seguente:
Sto creando un'applicazione che dovrebbe permettere di fare varie operazioni su un pc in remoto, tra cui l'elenco delle directories e dei files..
Per fare questo ho usato un winsock e una variabile tipo stringa che uso per passare l'intera lista delle directories..Tutto sembrava funzionare fino a che noto che esplorando le cartelle contenute in "Programmi", queste vengono tagliate; nel senso che il winsock taglia la variabile in 2 parti e le manda separatamente..
Dato che ho messo un identificatore all'inizio della variabile, in modo da sapere cosa c'è dentro(se directories,files,semplici stringhe ecc) in modo da inserirla in opportuni controlli(listbox,combobox,textbox...)
quando ricevo la seconda parte della variabile, non essendoci l'identificatore all'inizio, non riconosce il "tipo" di dati che contiene la stringa, quindi le cartelle non vengono inserite nel loro opportuno controllo. Posto un pezzo del codice interessato:
Nel client:
Codice sorgente - presumibilmente VB.NET |
Private Sub WS_DataArrival(ByVal bytesTotal As Long) On Error GoTo errore Dim data As String Dim dimensione As Long Dim analizzadata() As String WS.GetData data analizzadata = Split(data, vbCrLf) If UBound(analizzadata) > 1 Then dimensione = analizzadata(1) dimensioneData = bytesTotal 'MsgBox bytesTotal & "=" & dimensione End If Select Case analizzadata(0) Case "ListaDrives" 'caso lista dei drives For i = 2 To UBound(analizzadata) - 1 ComboDrive.AddItem (analizzadata(i)) Next ComboDrive.Text = "Seleziona Drive:" Case "ListaDir" ' caso lista delle directories ListDir.Clear For i = 2 To UBound(analizzadata) - 1 ListDir.AddItem (analizzadata(i)) Next Call cmdMostraFiles_Click Case "ListaFile" 'caso lista dei files ListFiles.ListItems.Clear For i = 2 To UBound(analizzadata) - 1 ListFiles.ListItems.Add , , analizzadata(i) Next Case "Disconnesso" Call cmdConnetti_Click Case Else MsgBox data End Select Exit Sub errore: End Sub
|
Il server invia un tipo di stringa del tipo:
Codice sorgente - presumibilmente Plain Text |
ListaDir 'il tipo di dati inviati
2340 ' la dimensione della stringa inviata
dir1 'inizia l'elenco delle directories
dir2
dir3
.
.
.
|
----------------------------------------------------
Spero di aver spiegato al meglio la situazione in cui mi trovo anche perchè telematicamente è difficile..  in caso chiedete.. Ciauz  |
|
|
gantonio (Normal User)
Guru^2
Messaggi: 1532
Iscritto: 09/09/2007
|
Hai fatto un errore di fondo, che e' quello che tutti commettono quando iniziano a programmare con la rete e i socket.
Hai dato per scontato che i dati siano ricevuti in blocco da un socket cosi' come sono trasmessi nell'altro socket. Questo NON e' affatto vero.
Il protocollo TCP garantisce SOLO che i dati arrivino e che siano nell'ordine corretto, MA e' padrone di "spezzarli" ed inviarli in quantita' che piu' ritiene opportune. Questo succede per diversi motivi, tra cui il fatto che le dimensioni dei pacchetti che viaggiano in rete, sono limitati e la "ricomposizione" avviene nel client.
Devi quindi "pensare" al tuo programma in modo diverso considerando che invii una testata con il numero dei byte trasmessi, fai in modo che questi siano TUTTI ricevuti prima di considerare che il prossimo blocco abbia una sua testata.
Cioe', se ricevi 2437 all'inizio del primo pacchetto, continua a ricevere dati fino a completare i 2437 byte e solo dopo considera che il prossimo numero rappresenta il nuovo pacchetto.
Ma fai ATTENZIONE al fatto che i 2437 byte si potrebbero completare nel bel mezzo di una stringa e che il prossimo pacchetto dei tuoi dati potrebbe iniziare proprio lì.
Per tentare di capirci, ad esempio, potresti avere delle chiamata alla Receive che ti forniscono pacchetti del tipo
1) ListaDir3299....
2) ....ListaDir2883...
3) ....File2787...
e devi essere tu a districarti tra i vari dati.
In genere si usa una "macchina a stati" per farlo, ma non e' complesso.
Ultima modifica effettuata da gantonio il 06/12/2007 alle 7:56 |
|
|
P4p3r0g4 (Member)
Guru
Messaggi: 1319
Iscritto: 29/12/2006
|
Io uso ragionare diversamente.
piuttosto che segmentare gli invii occupo totalmente l'invio (anche con l'utilizzo di spazi vuoti e caratteri nulli)
oppure (se posso) gli passo un "doevents" che mi invia il pacchetto in maniera corretta.
Certo che è un po più lento ma di solito i file (che sono gli invii "massicci") occupano totalmente + invii e gli altri non hanno bisogno di "immediatezze" della differenza di 1/100 di secondo.
Ultima modifica effettuata da P4p3r0g4 il 06/12/2007 alle 14:47 |
|
|
gmxsm (Normal User)
Newbie
Messaggi: 20
Iscritto: 06/12/2007
|
Hai dato per scontato che i dati siano ricevuti in blocco da un socket cosi' come sono trasmessi nell'altro socket. Questo NON e' affatto vero.
|
In effetti appena ho visto ciò che accadeva me ne sono reso conto e da qui ho realizzato che dovevo cambiare metodo utilizzando la dimensione dei pacchetti inviati dal server verso il client...
In genere si usa una "macchina a stati" per farlo, ma non e' complesso.
|
Su internet ho trovato questo:
http://www.dotnethell.it/forum/messages.aspx?ThreadID=15300
Anche essendo in .net,onestamente non ho capito nulla.. 
Potresti gentilmente farmi un esempio su come funziona?
Edit:gantonio,scusa ma rileggendo mi sono accorto di aver fatto richiesta di una cosa che precedentemente avevi già scritto
Devi quindi "pensare" al tuo programma in modo diverso considerando che invii una testata con il numero dei byte trasmessi, fai in modo che questi siano TUTTI ricevuti prima di considerare che il prossimo blocco abbia una sua testata.
Cioe', se ricevi 2437 all'inizio del primo pacchetto, continua a ricevere dati fino a completare i 2437 byte e solo dopo considera che il prossimo numero rappresenta il nuovo pacchetto.
Ma fai ATTENZIONE al fatto che i 2437 byte si potrebbero completare nel bel mezzo di una stringa e che il prossimo pacchetto dei tuoi dati potrebbe iniziare proprio lì.
|
Cmq ho notato inoltre che provando ad inviare le dimensioni di una stringa, questa non corrisponde con la variabile bytesTotal del data_arrival nel winsock..
Giusto per sapere se sbaglio: il valore ritornato dalla funzione Len(stringa) non dovrebbe essere uguale al valore di bytesTotal?
Nel frattempo di una risposta cerco ancora in giro ma penso che il problema stia nel fatto che qualcosa mi sfugge... Ultima modifica effettuata da gmxsm il 06/12/2007 alle 18:42 |
|
|
gantonio (Normal User)
Guru^2
Messaggi: 1532
Iscritto: 09/09/2007
|
Postato originariamente da gmxsm:Cmq ho notato inoltre che provando ad inviare le dimensioni di una stringa, questa non corrisponde con la variabile bytesTotal del data_arrival nel winsock..
Giusto per sapere se sbaglio: il valore ritornato dalla funzione Len(stringa) non dovrebbe essere uguale al valore di bytesTotal?[/QUOTE]
Non ho capito ... qual e' il problema?
[Quote]Nel frattempo di una risposta cerco ancora in giro ma penso che il problema stia nel fatto che qualcosa mi sfugge... |
Ma perche'? Ti ho risposto ... forse non sono stato chiaro ... |
|
|
gantonio (Normal User)
Guru^2
Messaggi: 1532
Iscritto: 09/09/2007
|
Postato originariamente da P4p3r0g4:
Io uso ragionare diversamente.
piuttosto che segmentare gli invii occupo totalmente l'invio (anche con l'utilizzo di spazi vuoti e caratteri nulli)
oppure (se posso) gli passo un "doevents" che mi invia il pacchetto in maniera corretta. |
Scusa ... ma come non "segmenti" un file AVI da 800 M ?
E a cosa serve un DoEvents eseguito su un client quando chi riceve, il server, ottiene i dati in piu' parti "indipendentemente" da come sono stati spediti dal client (per le note caratteristiche del protocollo TCP)?
Certo che è un po più lento ma di solito i file (che sono gli invii "massicci") occupano totalmente + invii e gli altri non hanno bisogno di "immediatezze" della differenza di 1/100 di secondo. |
Non ho capito nulla ...
Il fatto e' che tu, dal processo che spedisce dati con TCP, NON HAI alcun controllo sullo "spettezzamento" dei dati in arrivo e deve essere il layer applicativo a gestire il problema della ricostruzione temporale dei dati. Ultima modifica effettuata da gantonio il 06/12/2007 alle 19:08 |
|
|
gmxsm (Normal User)
Newbie
Messaggi: 20
Iscritto: 06/12/2007
|
Postato originariamente da gantonio:
Postato originariamente da gmxsm:Cmq ho notato inoltre che provando ad inviare le dimensioni di una stringa, questa non corrisponde con la variabile bytesTotal del data_arrival nel winsock..
Giusto per sapere se sbaglio: il valore ritornato dalla funzione Len(stringa) non dovrebbe essere uguale al valore di bytesTotal?[/QUOTE]
Non ho capito ... qual e' il problema?
[Quote]Nel frattempo di una risposta cerco ancora in giro ma penso che il problema stia nel fatto che qualcosa mi sfugge... |
Ma perche'? Ti ho risposto ... forse non sono stato chiaro ... |
No scusa è che tra studio e pc non avevo capito bene ciò che intendessi con:
Devi quindi "pensare" al tuo programma in modo diverso considerando che invii una testata con il numero dei byte trasmessi, fai in modo che questi siano TUTTI ricevuti prima di considerare che il prossimo blocco abbia una sua testata.
|
Avevo pensato dovessi confrontare i bytesTotal con quelli scritti nella stringa, e non mi trovavo con le quantità...
Grazie per i suggerimenti, avevo intuito una strada del genere, ma non avrei fatto molto senza di te... 
Cmq ora ci lavoro su, magari dopo martedì che ho esami  , e in caso non riuscissi...beh vedrai un nuovo post
p4p3r0g4 non ho ben capito che metodo usi:
Io uso ragionare diversamente.
piuttosto che segmentare gli invii occupo totalmente l'invio (anche con l'utilizzo di spazi vuoti e caratteri nulli)
oppure (se posso) gli passo un "doevents" che mi invia il pacchetto in maniera corretta.
Certo che è un po più lento ma di solito i file (che sono gli invii "massicci") occupano totalmente + invii e gli altri non hanno bisogno di "immediatezze" della differenza di 1/100 di secondo.
|
ma non penso sia proprio "corretto"..Soprattutto se si tratta di file grossi.. |
|
|
P4p3r0g4 (Member)
Guru
Messaggi: 1319
Iscritto: 29/12/2006
|
Postato originariamente da gantonio:
Postato originariamente da P4p3r0g4:
Io uso ragionare diversamente.
piuttosto che segmentare gli invii occupo totalmente l'invio (anche con l'utilizzo di spazi vuoti e caratteri nulli)
oppure (se posso) gli passo un "doevents" che mi invia il pacchetto in maniera corretta. |
Scusa ... ma come non "segmenti" un file AVI da 800 M ?
E a cosa serve un DoEvents eseguito su un client quando chi riceve, il server, ottiene i dati in piu' parti "indipendentemente" da come sono stati spediti dal client (per le note caratteristiche del protocollo TCP)?
Certo che è un po più lento ma di solito i file (che sono gli invii "massicci") occupano totalmente + invii e gli altri non hanno bisogno di "immediatezze" della differenza di 1/100 di secondo. |
Non ho capito nulla ...
Il fatto e' che tu, dal processo che spedisce dati con TCP, NON HAI alcun controllo sullo "spettezzamento" dei dati in arrivo e deve essere il layer applicativo a gestire il problema della ricostruzione temporale dei dati. |
sbagli di fondo.
col mio metodo non ho affatto bisogno di un "Layer Applicativo" |
|
|
gantonio (Normal User)
Guru^2
Messaggi: 1532
Iscritto: 09/09/2007
|
Sara' che sbaglio ... ma il tuo metodo ancora non si e' capito perche' non hai spiegato come trasmetti il file da 800 M ...
Ultima modifica effettuata da gantonio il 07/12/2007 alle 1:00 |
|
|
| 
