On 19-apr-06, at 09:56, Gualeni Giovanni wrote:
Quindi per mandare la stringa "READ" seguita da quei due caratteri
basta che scrivi normalmente "READ" in terminale seguito dal tasto
return.
La stringa READ, sul server cui e' destinata, fa il suo dovere (mi
invia dei dati) se sto lavorando su una macchina WIN. Su Mac premo
return e il prompt va a capo senza che accada nulla.
Ok, quindi dici che se usi il programma telnet di Windows, dopo aver
scritto "READ" ed esser andato a capo ricevi la risposta che ti
dovresti aspettare dal server, mentre se usi telnet di Mac OS X e
digiti lo stesso testo andando a capo, non ricevi nessun risultato.
Se non è giusto correggimi.
Da manuale:
The Macintosh line ending, Chr(13)
The Unix line ending, Chr(10)
The Windows line ending, Chr(13)+ Chr(10)
Se il server vuole come stringa READ + Chr(13) + Chr(10), su WIN
funziona. Come aggiungo il Chr(10) mancante nella stringa che
scrivo sul Terminale?
Attento Giovanni!
Quelli sono solo i valori delle proprietà della classe EndOfLine di
REALBasic! Significa semplicemente che l'espressione
"EndOfLine.Macintosh" ha come valore Chr(13) e che l'espressione
"EndOfLine.Windows" ha valore Chr(13)+Chr(10). Non ha senso
generalizzare quei valori alle altre applicazioni del sistema.
Infatti, ti ripeto che telnet di Mac OS X usa chr(13)+chr(10) per
segnalare l'andatura a capo (non solo chr(13) come sostieni).
Anche telnet di windows usa quei due caratteri.
Se non ci credi basta che scrivi una piccola applicazione in rb che
legge quello che gli mandi via telnet e ti fornisce gli ultimi due
caratteri.
Ti chiederai dunque: come mai sotto OS X il server sembra non
rispondere e sotto win si? È colpa di Mac OS X? La risposta è no. La
colpa è del server che non sa leggere bene ^_^
Quello che infatti forse ti sfugge è che c'è una piccola differenza
tra telnet di Mac OS X e Windows.... tuttavia MOLTO importante.
Telnet di Windows, appena schiacci un tasto, manda SUBITO il valore
corrispondente al tasto premuto.
Ciò significa che se scrivo "READ"+chr(13)+chr(10) da Windows, telnet
manda ben 4+1=5 pacchetti TCP/IP. 4 corrisponde alla lunghezza della
stringa "READ", mentre i due byte chr(13)+chr(10) vengono mandati
insieme in un pacchetto TCP/IP (per questo ho scritto 1).
Quindi se scrivi qualcosa di sbagliato usando telnet sotto windows,
non puoi cancellare! Perchè tutto quello che hai scritto fin'ora è
stato mandato al server! Quindi devi riscrivere la linea da capo (nel
caso meno sfortunato). Inoltre non vedi neanche quello che scrivi...
odio telnet di windows!
I programmatori di telnet per OS X sono stati invece più
intelligenti :-)
Sotto OS X viene inviato un pacchetto TCP per ogni linea, al posto
che per ogni carattere.
Quindi se scrivi in telnet "READ", in realtà il server non ha ancora
ricevuto niente, la linea che hai scritto verrà inviata al server
solo quando andrai a capo. Ciò permette anche di correggersi se si
fanno degli errori... dato che la linea non è stata ancora mandata
puoi cancellare, riscrivere, ricancellare, ecc... ed infine andare a
capo! Inoltre la linea viene inviata al server utilizzando solo 1
pacchetto TCP/IP!.. ciò naturalmente vale se non ti metti a scrivere
una linea lunga più di 9168 caratteri (mi sembra sia questo il limite
di dati per pacchetto TCP/IP... correggetemi!).
E in telnet di MAC OS X si vede anche quello che si scrive..
Quest'ultima tecnica, di mandare il testo di una linea tutto in una
volta, è utilizzata anche da telnet di linux, se non sbaglio, e anche
dal programma "netcat" (per fare una riprova che quello che dico è
vero, scaricati netcat per windows e vedrai che anche se sei sotto
windows il server non ti risponderà).
Netcat è molto più potente di telnet, ma per connetterti ad un server
alla porta "porta", basta che scrivi: "nc server porta".
Quindi la colpa non è di telnet per os x... perchè il fatto di
mandare una linea tutta in una volta viene usata anche dai normali
programmi... Se in realbasic scrivi:
TCPSocket1.write "READ"+chr(13)+chr(10)
verrà inviato un solo pacchetto TCP/IP contenente quella stringa, che
il software che gira sul server non riuscirà ad interpretare.
Probabilmente il software si aspetta che il chr(13)+chr(10) gli venga
trasferito in un pacchetto TCP/IP a parte. Quindi il codice per la
lettura dell'input potrebbe essere qualcosa del genere:
(DataAvailable è l'evento che si attiva nel momento in cui il socket
riceve un pacchetto TCP/IP)
Sub DataAvailable()
Dim content As String
Content = me.readAll
if Content=chr(13)+chr(10) then
// Ho ricevuto un pacchetto TCP/IP che mi dice che "i caratteri
ricevuti fin'ora sono pronti di interpretare"
"Interpreta la stringa Buffer"
else
// Il contenuto del pacchetto è diverso da chr(13)+chr(10) quindi
aggiungi quello che l'utente ha scritto
// al Buffer.
"aggiungi all'array di caratteri Buffer il contenuto della
variabile Content"
EndIf
End
Quindi quando gli scrivi da windows "READ"+chr(13)+chr(10), l'evento
DataAvailable si attiva ben 5 volte: 4 volte vengono eseguiti i
comandi dopo ELSE, una volta (l'ultima) viene esegutio il metodo
"Interpreta Buffer".
Quando da telnet di Mac OS X gli scrivi la stessa stringa,
DataAvailable si attiva solo 1 volta, e dato che:
"READ"+chr(13)+chr(10) è diverso da chr(13)+chr(10), vengono eseguiti
solo i comandi dopo l'ELSE. Quindi la stringa che mandi non viene mai
interpretata e dunque non vedi la risposta.
Io ho cercato solo di ipotizzare quale sia la causa più probabile del
non funzionamento, se magari mi dessi più informazioni di debug
potrei aiutarti più specificatamente.
Matteo
|