15/11/09 15:42
Il Totem
Postato originariamente da carant:
Il timer va bene, perchè se io lo faccio solo scrivere da una parte non si blocca...
Quando va a leggere è il problema: quando dico Read vuole buffer che è byte, offset che è 0,
la lunghezza del buffer che è Byte(il buffer intendo) e che non posso capire, perchè Length non è un membro di byte...
quello che bloccava era dim c(client.receivebuffersize) as byte perchè receivebuffersize restituisce integer infatti se scrivo
dim c as byte
c=client.receivebuffersize l'errore me lo da.
FORSE è così, non lo so.... Provo a spostare start e vedo...
se vi viene un'illuminazione mi dite.
Ciao.
Il timer va bene, perchè se io lo faccio solo scrivere da una parte non si blocca...
Quando va a leggere è il problema: quando dico Read vuole buffer che è byte, offset che è 0,
la lunghezza del buffer che è Byte(il buffer intendo) e che non posso capire, perchè Length non è un membro di byte...
quello che bloccava era dim c(client.receivebuffersize) as byte perchè receivebuffersize restituisce integer infatti se scrivo
dim c as byte
c=client.receivebuffersize l'errore me lo da.
FORSE è così, non lo so.... Provo a spostare start e vedo...
se vi viene un'illuminazione mi dite.
Ciao. Hai sbagliato tutto. Buffer non è Byte, ma Byte(), ossia un array di Byte; la lunghezza non è Byte, ma Integer (altrimenti potresti leggere solo 255 valori alla volta). Length è membro di Array, e quindi anche di un array di Byte, ma non è membro di Byte.
C = Client.ReceiveBufferSize è solitamente un valore troppo alto per essere contenuto in un Byte, quindi certamente ti dà errore (di overflow). Metterlo tra parentesi significa specificare la lunghezza dell'array.
Sai cos'è un array? Se la risposta è no, metti da parte il tuo progetto per un attimo e studia gli array.
ci sono milioni di esempi già fatti probabilmente ho preso l'esempio sbagliato...
ma sicuramente la tecnica giusta non è un timer... concettualmente sbagliato...
per affrontare in maniera pulita questo problema secondo me bisognerebbe saper utilizzare i Thread e i Socket, gli eventi mancati su TcpListener e TCPClient li implementi.
appena ho un momento butto giù 2 righe di codice di esempio.
ma sicuramente la tecnica giusta non è un timer... concettualmente sbagliato...
per affrontare in maniera pulita questo problema secondo me bisognerebbe saper utilizzare i Thread e i Socket, gli eventi mancati su TcpListener e TCPClient li implementi.
appena ho un momento butto giù 2 righe di codice di esempio.
Dire che non è giusta significa che è sbagliata, ma se fosse sbagliata non funzionerebbe, e invece funziona. Semmai non è la migliore, o la più elegante, o la più adatta, ma non è sbagliata.
Comunque ti avverto che TcpListener e TcpClient sono molto simili agli oggetti Socket, solo specializzati per un certo compito. E per implementare gli eventi devi usare un timer, quindi non puoi farne a meno.
Certo, tu dici di usare un Thread diverso in cui c'è un ciclo infinito che continua a controllare se si sono ricevuti dati, ma questo può crearti problemi (operazioni cross-thread ad esempio), ed inoltre il ciclo è un carico di lavoro molto più pesante per la CPU che non un controllo ad intervalli regolari. Inoltre questo genererebbe lo stesso problema di cui tu hai accusato i timer: il ciclo fornisce informazioni a intervalli possibilmente anche minori di 1ms, e se le operazioni si accavallassero, succederebbe ancora più spesso.
Infine, l'intervallo del timer non è mai su 1ms: già a 50ms non si distingue più la differenza. E poi, se le operazioni da eseguire impiegano più dell'intervallo, non si generano problemi, poiché, trattandosi di eventi, appunto, ognuno è indipendente dall'altro e le prime operazioni vengono completate prima delle seconde; niente si blocca.
Ultima cosa: il timer implementa di nascosto un thread, solo che l'evento viene generato nel thread principale e non in quello secondario.
aaa
