Questo sito utilizza cookies solo per scopi di autenticazione sul sito e nient'altro. Nessuna informazione personale viene tracciata. Leggi l'informativa sui cookies.
@Gianluca87:Sono qui proprio perchè non lo so fare, se me lo volete dire va bene se no niente...
Poi per Il Totem: quindi cosa devo modificare?? devo mettere timer1.stop?? scrivi il codice...
Grazie della risposta. Ciao!!!
@Gianluca87:Sono qui proprio perchè non lo so fare, se me lo volete dire va bene se no niente...
Poi per Il Totem: quindi cosa devo modificare?? devo mettere timer1.stop?? scrivi il codice...
Grazie della risposta. Ciao!!!
non ho la più pallida idea di quanti dati tu debba gestire mi sembra ad ogni modo sbagliato usare un timer per una cosa del genere...
prova a guardare qusto link ci sono anche i sorgenti
http://www.codeproject.com/KB/IP/mycodefaraz.aspx
non ho la più pallida idea di quanti dati tu debba gestire mi sembra ad ogni modo sbagliato usare un timer per una cosa del genere...
prova a guardare qusto link ci sono anche i sorgenti
http://www.codeproject.com/KB/IP/mycodefaraz.aspx
Ah certo, perchè un while(true) che blocca tutta l'applicazione è meglio, vero? Non hai neanche notato che il client non riesce neppure a ricevere dati dal server, proprio perchè manca il timer.
Può anche essere non particolarmente elegante usare un timer, ma non è sbagliato (anche perchè TcpClient e TcpListener non espongono alcun evento, e sarebbe impossibile fare altrimenti). Può anche "sembrarti" sbagliato, ma rimane sempre un'impressione finché non proponi una soluzione più efficiente. E' logica, si tratta di dati concreti.
@carant: come cosa devi modificare? L'ho detto prima: devi tirare Start fuori dal codice gestito nel timer, o verrà richiamato decine e centinaia di volta. Prova a metterlo in FormLoad o FormShown se più di aggrada.
non ho la più pallida idea di quanti dati tu debba gestire mi sembra ad ogni modo sbagliato usare un timer per una cosa del genere...
prova a guardare qusto link ci sono anche i sorgenti
http://www.codeproject.com/KB/IP/mycodefaraz.aspx
Ah certo, perchè un while(true) che blocca tutta l'applicazione è meglio, vero? Non hai neanche notato che il client non riesce neppure a ricevere dati dal server, proprio perchè manca il timer.
Può anche essere non particolarmente elegante usare un timer, ma non è sbagliato (anche perchè TcpClient e TcpListener non espongono alcun evento, e sarebbe impossibile fare altrimenti). Può anche "sembrarti" sbagliato, ma rimane sempre un'impressione finché non proponi una soluzione più efficiente. E' logica, si tratta di dati concreti.
@carant: come cosa devi modificare? L'ho detto prima: devi tirare Start fuori dal codice gestito nel timer, o verrà richiamato decine e centinaia di volta. Prova a metterlo in FormLoad o FormShown se più di aggrada.
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.
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.
Ultima modifica effettuata da carant il 14/11/2009 alle 21:06
Il timer va bene, perchè se io lo faccio solo scrivere da una parte non si blocca...
ma cosa centra?
scusa... allora mettiamo caso che il tick del timer lo imposti a 1 millisecondo..
se il secondo tick scatta prima che tu abbia finito le operazioni sul primo cosa succede?
te lo dico io? si pianta tutto...i tick del timer sono degli eventi...come tali vengono scatenati sul tick del timer...quindi....rischi di accavallare le operazioni sul socket
chiaramente... se invii come dati sempre la stringa "Ciao" da solamente un client sulla stessa macchina della applicaizione server... il problema non lo vedi...
tienine conto...
Quindi metto timer1.stop() dopo aver scritto... così va bene??
comunque si bloccava con il pulsante per leggere non con il timer. comunque provo a fare come dici tu.
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.
Testo quotato
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.
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.
