Newsgroup: it.comp.programmare
Titolo: Modem

sto realizzando un mini protocollo personalizzato per far scambiare dei
dati tra 2 PC via modem.
per ora sto provando con i PC collegati tra di loro con il solo cavo
seriale senza modem (e quindi senza comandi AT, ma solo il mio nudo
protocollo).
ho inserito il controllo di flusso hardware, in modo che chi trasmette
aspetti se quello che riceve non e' pronto.
fin qui nulla di preoccupante.
la mia domanda e' la seguente:
ma quando ci sara' il modem, il controllo di flusso hardware viene
rimbalzato da un modem all'altro, oppure rimane locale tra modem e PC?
e se rimane locale, come faccio a sapere che l'altro PC non e' pronto
per ricevere i dati?
ciao
donCiccio

 wrote in message
news:9srqdc$ag1$1...@nreada.inwind.it...

E' locale, ovviamente.
Non lo sai. Non sai nulla dell'altro PC. Ci pensano i modem. Tu parli
con il tuo modem, lui parla con l'altro modem e l'altro modem parla con
l'altro PC.
Fra l'istante in cui tu mandi un carattere al tuo UART e quello in cui
l'altro PC lo legge dal sua UART possono passare anche dei minuti. Sia
il tuo UART che il tuo modem che l'altro modem che l'altro UART hanno
dei buffer.
--
Andrea Ferro
---------
Brainbench C++ Master. Scored higher than 97% of previous takers
Scores: Overall 4.46, Conceptual 5.0, Problem-Solving 5.0
More info 
http://www.brainbench.com/transcript.jsp?pid=2522556


i buffer per quanto siano grandi potrebbero non bastare.
se il pc che trasmette inizia ad inviare un pacchetto da 10000 byte, e
chi riceve (il software intendo) non e' pronto, che fine fanno quei
dati?
sei sicuro che i modem non si scambino anche l'informazione di sono
pronto a rivecere?
ad esempio:
il pc che riceve non e' pronto e segnala localmente con il controllo di
flusso hardware questo suo stato al modem, il modem non puo' trasferire
i dati ricevuti al pc e quindi li terra' nel suo buffer.
ad un certo punto il buffer del modem sara' pieno, il modem che fa?
1-butta via i dati in eccesso?
2-dice all'altro modem femati che sono pieno?
nel caso 2 il modem che trasmette che se ne fa di questa informazione?
1-accetta ancora dati dal pc che trasmette fino a riempire il suo buffer
per poi dire anche lui al pc attraverso il controllo di flusso hardware
che e' pieno?
2-se ne frega e continua a trasmettere, ed usa il controllo di flusso
hardware solo per segnalare i limiti del suo buffer interno? (tipo
comunicazione DCE a 1200 e DTE a 115200, per cui sicuramente il suo
buffer interno si satura)
ciao
donCiccio

 buffer interno si satura)
Se nel protocollo modem2modem se ne frega, allora č rotto :-)
Se nel protocollo TDE-DCE se ne frega allora o č rotto o il cavo ha le
connessioni incrociate e non trasmette i segnali HW!


Andrea ti ringrazio!
una ultima conferma:
da quanto mi hai detto posso continuare a sperimentare il mio protocollo
basandomi solo sui segnali di controllo hardware, quando poi ci saranno
i 2 modem di mezzo, non cambiera' nulla, nessun carattere verra' perso,
la mia gestione degli handshake sara' corretta lo stesso. Giusto?
ciao
donCiccio

 wrote in message
news:2hMI7.12965$5l.2...@news1.tin.it...

Sbagliato. Il protocollo di handshake (HW o SW) serve per gestire il
flusso delle comunicazioni fra due device, ma non la sua correttezza.
Non è garantito che non ci siano errori di trasmissione ne che non
capitino caratteri perrsi.
Per questo esistono i protocolli di controllo degli errori che sono
un'altra cosa (uno viene usato anche fra modem e modem, ma la garanzia
totale comunque non la da).
Domanda: la tua comunicazione, intesa ad alto livello, è monodirezionale
o bidirezionale? Ovvero hai una applicazione che fornisce dati ad
un'altra o hai applicazioni che si scambiano messaggi? E ancora,
trasmette in continuo (un sensore remoto, per esempio) o a blocchi (FTP,
per esempio). Se è a messaggi, di che lunghezza? Pochi byte (tipo una
console interattiva)? Pochi KByte (tipo E-Mail)? Molti megabyte?


 console interattiva)? Pochi KByte (tipo E-Mail)? Molti megabyte?
sono messaggi suddivisi in blocchi con dimensioni variabili da 10 byte
(solo header,id messaggio, checksum), fino a max 32768 byte per blocco.
si tratta di un controllo a distanza.
il server e' un macchinario industriale, controllato da un PC.
il client e' un normale PC che chiama il server via modem e lo interroga
ciclicamente, con messaggi di tipo e lunghezza differente, che possono
cambiare in numero e tipo a seconda delle scelte dell'utente che sta
usando il client.
ad esempio nel caso di trasferimento di file, i messaggi vengono
spezzettati in piu' segmenti, e finiscono con l'essere intercalati agli
altri messaggi minori scambiati ciclicamente (i due PC usano un mini
kernel multitask).
se fossi tu a dover fare questa comunicazione, che tipo di comunicazione
adotteresti?
ciao
donCiccio

 adotteresti?
Mi sfugge cosa è il server. Dici che è un macchinario industriale
controllato da un PC. Se è così quelli che comunicano via modem sono un
PC remoto e il PC che controlla il macchinario industriale. In questo
caso direi che la cosa migliore è usare una normale socket TCP-IP
installando quest'ultimo opportunamente su entrambe i PC (come dipende
dall'OS degli stessi). A questo punto avrai SLIP o PPP per gestire il
link fra i due, PAP o CHAP o simili per l'autenticazione del chiamante,
IP per il protocollo dei pacchetti, TCP per il protocollo di sessione e
una qualche versione di Socket per l'interfaccia applicativa. Su questa
devi solo mettere il protocollo fra il server e il client (cioè i tuoi
messaggi).
Oppure mi è sfuggito qualche cosa.



si ti e' sfuggita una cosa:
non so come realizzare tutto quello che hai scritto :-)
il SO e' il DOS per il macchinario, windows9x(o DOS) per il client.
dove posso trovare del materiale per realizzare un socket TCP/IP ?
ciao
donCiccio

 dove posso trovare del materiale per realizzare un socket TCP/IP ?
Ho provato a cercare per qualche giorno. So che esistevano ma ... il DOS
č morto da oltre 6 anni il che nel mondo informatica corrisponde a
un'era geologica.
A parte il consiglio di migrare ad un OS piů moderno (se il sistema č
ancora sotto sviluppo č certamente la cosa migliore da fare) se lavori
con il DOS forse ti conviene fare tutto da te.
A qusto punto ti sviluppi delle routine a basso livello che gestiscono
l'IO su seriale sfruttando gli interrupt e poi le richiami dall'alto. Un
insieme di routine ad alto livello dovrebbero gestirti la creazione
della connessione e il riconoscimento del chimante (o la chiamata,
dall'altro lato) e poi passare il controllo ad un layer di sessione. Le
routine a livello intermedio che gestiscono la sessione dovrebbero
occuparsi di definire una pacchettizzazione con eventuale
controllo/correzione errori e sopratutto con il risequencing dei
pacchetti e la ritrasmissione. Puoi fare tutto in un colpo o spezzare la
cosa in due sottolivelli come avviene con IP e TCP. Sopra queste metti
l'applicazione con il suoi messaggi e il loro formato.
Dato che la comunicazione č sempre a singolo canale (doppio solo nel
senso che č bidirezionale) non dovrebbe essere difficile gestire la



e' quello che ho fatto, esattamente come lo hai descritto tu.
grazie di cuore per le info preziose che mi hai dato.
ciao
donCiccio

 grande dimestichezza con i sistemi windows in genere.
Ce credo. Win95 non ha neppure un kernel real-time. Come minimo ci
vorrebbe NT. Ma per un 386 è pesantuccio!



eppure saro' un illuso, ma penso che un device driver, che mi gestisca
un interrupt hardware a 1 msec, si possa fare anche con win95.
ciao
donCiccio

 un interrupt hardware a 1 msec, si possa fare anche con win95.
A livello di device driver potresti riuscirci. Ma avresti problemi ad
avere una latency decente a livello di riflessione dell'interrupt
all'applicativo. E scrivere tutto l'applicativo a livello di DD ... fai
prima a installare linux o NT.



vorrei scrivere solo una serie di routines che non avranno nulla a che
fare con video, tastiera o dischi, ma solo con I/O di schede
proprietarie.
quello che mi fa pensare che si possa fare e' il fatto che una comune
linea seriale a 115200 baud con 1 start 8 bit 1 stop e fifo level a 8
genera un interrupt ogni 0,7 msec, e non ho mai avuto problemi di mal
funzionamenti con win95 con la seriale cosi' impostata.
Per quel che riguarda la latenza, se e' costante non e' un problema
anche se alta, se e' variabile, basta poter leggere quanto vale, (es: il
counter del timer 0 ammesso che windows lo permetta) e inserirlo nei
conti.
ciao
donCiccio

 wrote in message
news:h7tM7.19564$4M2.5...@news2.tin.it...

Frena. Un conto č gestire un interrupt ogni millisecondo, un altro č se
quell'interrupt riguarda l'I/O seriale.
In uscita non hai problemi (quando ti arriva l'interrupt di buffer vuoto
hai tutto il tempo che vuoi per spedire una nuova serie di 16 byte, al
massimo rallenti un pochino il througput). In ingresso hai una FIFO di
16 caratteri in cui puoi impostare l'interrupt a 14 o anche a 8 (o anche
meno, ma non serve). Supponendo che tu imposti l'interrupt a 14 dal
momento in cui ti arriva l'interrupt hai ancora come minimo due cicli
carattere completi prima di un overrun della FIFO. Se la imposti a 8 ...
ne hai ben 8. Pertanto la latency ti interessa relativamente (puň essere
lunga e/o veriabile senza grossi problemi). In termini di device driver
rispondi all'interrupt e leggi tutti i caratteri in ingresso fino a
svuotare il buffer (potresti trovarne piů di 8 se la latency č alta o
meno di 8 se la trasmissione non č continuativa). Questo lo fai
tranquillamente anche con Win95.



a me questo basta, ma non sono riuscito a farlo :-)
ripetendo:
i numeri che ti ho dato prima sono corretti, quindi una seriale risponde
ad un interrupt che gli si presenta ogni 0,7 msec, ed io dovrei fare piu
o meno lo stesso.
La latenza non e' costante?, non e' un grosso problema, mi basta poter
leggere un counter hardware per sapere quanto dopo ho risposto
all'interrupt e tenerne conto nella mia routine.
ciao
donCiccio

 all'interrupt e tenerne conto nella mia routine.
Non esiste un counter come questo. Nel device driver devi leggere fino a
che il buffer FIFO si è svuotato. Il loop è del tipo:
repeat
    input byte from serial
    input status
until status byte pending = none


 until status byte pending = none
questo lo so, ma perche' me lo dici?
io volevo fare un paragone con la seriale, non realizzare un device
driver per la seriale.
il concetto che volevo esprimere e che se ho una seriale che funziona a
115200 baud con 8 bit dati + start + stop e fifo level a 8, ottengo:
115200 / (1+8+1) / 8 = 1440  interrupt al secondo
io ho una scheda che mi genera 1170 interrupt al secondo, cioe' di meno
della su detta linea seriale.
quindi: visto che la linea seriale in win95 funziona benissimo, *a
saperlo fare*, un device driver per la mia scheda dovrebbe funzionare
altrettanto bene.
ciao
donCiccio

 altrettanto bene.
Sicuro. Sono abbastanza convinto che sia possibile scrivere un device
driver che risponde a 1170 interrupt al secondo. Salvo che non puoi
garantire che questo avvenga SEMPRE (ti dico per esperienza che ad alte
velocità a volte anche sotto NT la seriale ti perde qualche carattere,
se usi il DD di default. E sotto Win95/98 è peggio).
E comunque tutta la gestione relativa all'interrupt deve avvenire nel
device driver. Non puoi permetterti di avere quella frequenza di
chiamate a livello applicativo. Se come per la seriale all'applicativo
basta essere attivato dopo la ricezione di un numero relativamente alto
di caratteri (qualche decina o alcune centinaia) allora tutto Ok.


 di caratteri (qualche decina o alcune centinaia) allora tutto Ok.
si esatto, l'applicativo puo' essere informato con ritardo di cio' che
fa l'handler dell'interrupt. Gia' ora nel mio programma DOS e' cosi'.
grazie mille
ciao
donCiccio