Newsgroup: it.comp.lang.visual-basic
Titolo: [ANALISI] trasmissione dati

ciao a tutti,
ho la necessità di trasferire informazioni da più client remoti ad un server
centrale. Vorrei compiere questa operazione via Internet oppure in
connessione telefonica diretta.
Consigli?
saluti
Cristina (stamane un pò incasinata per 'stà storia caduta tra capo e collo!)

 ha scritto nel messaggio
news:Oteu7.138852$dJ3.1...@news1.tin.it...


 dovresti farcela ...
no, la connessione deve avvenire una tantum. Inoltre cosa significa farlo
con winsock? Mi puoi dare qualche indicazione più specifica o dove reperire
informazioni?
Mi sorge però un dubbio: per poter effettuare una connessione ftp ho bisogno
di conoscere l'IP del client al momento, o no? Se così dovrei conoscere gli
IP di tutti i client mano mano che vanno su Internet, insomma verrebbe meno
l'automatismo! Dico corbellerie?
cmq grazie



Sei la Cristina "delle piante, ascensori e Pasquale" o un'altra? No,
perché sarà un problema comune a tutte le Cristine avere a che fare con
Winsock... :-))
Comunque...
Indipendentemente dal tipo di connessione (internet, telefono,
satellite, passaparola), posto di utilizzare il protocollo TCP, potresti
utilizzare Winsock per inviare tali informazioni tra client e server.
In pratica il server si mette in ascolto su una porta, il client
richiede una connessione, il server acconsente e da quel momento possono
scambiarsi dati, sia di tipo stringa che binari.
Su MSDN trovi un esempio di come ralizzare un sistema di questo tipo
(cerca Winsock), mentre su 
groups.google.com
 trovi diversi post che
trattano l'argomento ed in particolare la connessione di più client ad
uno stesso server (in pratica si tratta di utilizzare sul server più
istanze del controllo Winsock).
In alternativa al controllo Winsock potresti usare l'API relativa, ma
sinceramente non saprei dove indirizzarti per reperire delle funzioni
già pronte a sostituire il controllo: tempo fa ho trovato qualcosina, ma
sarebbe da riscrivere totalmente...
Ciao,
Moreno
#sirri#@#
morenosoft.com#
(togliete "#" dall'indirizzo)
Moreno Sirri VB Site - 
http://www.msvbsite.net
---------------------------------------------------------------------------
Le risposte alle tue domande le trovi sul Sito Comune di questo NewsGroup:
 
http://www.it-lang-vb.net
---------------------------------------------------------------------------

 ha scritto nel messaggio
news:iOeu7.144071$dJ3.1...@news1.tin.it...


contattare e se i client sono su internet l'ip varia...
Se il server li contatta, non è più server!
Se il server ha IP fisso, no prob, poiché quando il client richiede la
connessione gli comunica il suo IP (dinamico);
Se il server, invece, ha anch'esso IP dinamico, un'alternativa
(utilizzando sempre Internet, chiaro, altrimenti vale quello che hai
detto tu a proposito di una vpn o di un server di accesso remoto)
potrebbe essere quella di archiviare in un db su un server esterno i
vari IP di client e server: quando un PC (client o server che sia) si
connette ad Internet, accede a tale db, registra il suo IP attuale e
legge gli IP degli altri eventualmente connessi.


 l'automatismo! Dico corbellerie?
Devi solo ribaltare il problema per risolverlo... l'indirizzo noto e' quello
del server, che deve avere un servizio FTP attivo, a cui si connettono tutti
i client
Una cosa simile puo' essere fatta anche attraverso le API della libreria
standard "wininet.dll" (io per esempio ho usato queste).
Prova a dare un occhiata a "Microsoft Win32 Internet Functions Overview"
sempre su MSDN, in particolare queste funzioni dovrebbero essere quelle
necessarie e sufficienti:
InternetOpen
InternetConnect
FtpSetCurrentDirectory
FtpPutFile
InternetCloseHandle
Ciao
--
Luca Dormio - 
luca....@tin.it
________________________________
"Marty, non stai ragionando in maniera quadridimensionale"
Dr. Emmett L. Brown

 utilizzare Winsock
...scusa, significa via Internet? (sai, noi Cristine siamo un pò dure...)

(sai, noi Cristine siamo un pò dure...)
Ehm, no dai!! Se ti sente la mia ragazza (si chiama Cristina pure lei),
poi pensa che l'abbia detto io... :-))
P.S:
Vieni al Meeting? (Montecatini, 13/10, maggiori info
www.it-lang-vb.net/Meeting
)


 Vieni al Meeting? (Montecatini, 13/10, maggiori
... e lei ci viene?

... e lei ci viene?
lei??


 ricordo assolutamente che voglia dire...
vuole dire che sta aprendo con vb5 un vbp vb6.
se non ci sono controlli o funzioni (es. replace) propri del 6, dovrebbe --
dico: dovrebbe, al condizionale -- bastare aprire il .vbp con un editor tipo
notepad ed eliminare la riga. lo stesso per eventuali .bas. per vedere in
cosa differiscono, basta aprire un bas vb5 e uno vb6 con un editor.

vuole dire che sta aprendo con vb5 un vbp vb6.
grazie, però se stiamo parlando dello stesso progetto, l'autore ha
scritto che è stato sviluppato con VB5... (almeno uno dei due... sta a
vedere che l'altro l'ha fatto in VB6? Mah...)


>
cristina ha vb5, chi l'ha dato al s.c. ha usato vb6.
ciao, j.

 notepad ed eliminare la riga.
Se ha VB5 con SP3 non è necessario, basta dare "Continua".
Se non ha SP3, consiglio caldamente di installarlo. Risolve un mucchio
di rogne. :-))
Se ci cono problemi con i controlli di versione diversa, può scaricare
quelli del 6 da qui [con il solito disclaimer: _A ME_ funzionano,
per gli altri non mi assumo responsabilità di alcun genere, claro ?
:-) ]:
"INFO: CAB Files Distributed with Visual Basic 6.0"
http://support.microsoft.com/support/kb/articles/q193/3/66.asp
Se servono le funzioni stringa che mancano nel VB5:
"HOWTO: Simulate Visual Basic 6.0 String Functions in VB5"
http://support.microsoft.com/support/kb/articles/Q188/0/07.ASP
Bye, G.


http://support.microsoft.com/support/kb/articles/Q188/0/07.ASP
wow, thnx! E pensare che io me l'ero fatte manin manina, sia per vb5
che, tutt'ora, per vbs... :-((


> distretto).
MS> Volendo potresti creare un server FTP in VB ed
Volendo si può  scrivere un compilatore C in  COBOL...  Non ritengo VB
adatto a fare un buon server FTP per la difficoltà - rispetto ad altri
linguaggi -  ad andare in  multithreading e il multithreading  (o alla
peggio il multitasking - ma anche qui non vedo VB molto ben versato) è
fondamentale per un buon server FTP
MS> attivarlo solo quando il client (tramite winsock) invia la richiesta di
MS> upload, ma sinceramente, se hai la possibilità di installare un server
MS> FTP "vero", te lo consiglio... tanto lavoro in meno...
Sconsiglio IIS viste  le ultime vulnerabilità mostrate (e  la patch di
M$ non ha risolto molto, anzi...)
MS> Questo perché il protocollo FTP è più sicuro nell'invio di file, poiché
MS> via TCP/IP dovresti tener manualmente traccia della successione dei
MS> pacchetti inviati, dal momento che questi non è detto "arrivino al
MS> server nello stesso ordine in cui li ha spediti il client" (detto papele
MS> papele).
Ahia, qui fai confusione!
FTP è uno strato che sta sopra TCP/IP, non alternativo. E il riordino dei
pacchetti fuori ordine lo fa lo stack TCP/IP.
MS> Se oltre a questo vuoi anche che i PC si scambino altre informazioni,
MS> puoi benissimo implementare una comunicazione TCP con Winsock, come ti
MS> spiegavo nell'altro post.
Beh, allora se non ci sono grossi file va bene anche la simulazione di
un POST con HTTP - per file  grossi occhio che HTTP ha timeout di gran
lunga più brevi  di FTP. Bisogna però creare  un meccanismo decente di
autenticazione  che devi  gestirti a  manina (i.e.  i  dati potrebbero
essere criptati con la chiave privata del client, il server identifica
il client  e verifica che  i dati siano  stati criptati con  la chiave
privata del client usando la chiave pubblica in suo possesso...).
Dall'altra parte puoi metterci ASP o PHP - per IIS valgono i caveat di
prima -.
Hmmm...   In   questi  problemi  a  me  piacerebbe   assai  Java  come
soluzione. Fare  un server per un  nuovo protocollo ed  esporlo ad una
rete pubblica può  avere delle implicazioni di sicurezza  non banali e
con Java  certi problemi  si risolvono meglio...  Ma qui  Java c'entra
come i cavoli a merenda, scusate.
--
Gian Uberto| main(){printf(&unix["\021%six\012\0"],(unix)["have"]+"fun"-0x60);}
Lauri      |                        David Korn, 1987 ioccc best one liner 
(aka saint)|-------------------------------------------------------------------
em@ail: 
sa...@eng.it
 ( vedere X-nospam nello header - see X-nospam in header )

 di rogne. :-))
yesssssssssss.............
SP3 è la soluzione.  Ho dato "continua", potrà pregiudicare il corretto
funzionamento?
thx
cris

 lei??
cerrrrrto. No, non "lei" tu! Ma lei lei (cristina la tu' bambola...)

 ha scritto nel messaggio
news:upu854...@mail.eng.it...
Tagliatina con rucola=CUT
posso concordare e no con te...
dipende quello che deve fare Cristina...
se deve gestire migliaia di collegamenti client di cui molti contemporanei
Cristina ha sbagliato ng e deve andare su quello di java (ed hai ragione al
101 %)
se deve gestire una decina di collegamenti client fa bene a stare in questo
ng e va bene quello che dice moreno (ed hai ragione al 99,99%)
perche in cobol un compilatore C...ed il PROLOG?!
:-P
Salute e pace all over the world!

pacchetti fuori ordine lo fa lo stack TCP/IP.
Eh, già, scusa, mi sono spiegato male, anche perché il thread sta
lentamente virando verso i confini della mia ignoranza... dove nessun
neurone è mai giunto prima... :-))). 
Pero una volta ho provato ad inviare un file, suddividendolo in n
pacchetti ed inviarlo tramite Winsock ed il risultato è stato pessimo
(senza tener conto della lentezza)...




 :-))
mmm... mi sa di no... ha un convegno all'università proprio quel
giorno... se magari glie lo spostano sì, ma sarà dura...


 ha scritto nel messaggio
W> news:upu854...@mail.eng.it...
W> Tagliatina con rucola=CUT
W> se deve gestire una decina di collegamenti client fa bene a stare in questo
W> ng e va bene quello che dice moreno (ed hai ragione al 99,99%)
Vedo che certi problemi non sono noti a tutti. 
Quando si fa  un server su una rete  esposta bisogna anche considerare
che esistono  delle persone che, o  per cattiveria o  per sentirsi ciò
che non sono,  si divertono a far malfunzionare in  maniera più o meno
distruttiva le macchine altrui.
Ci sono delle tecniche di  programmazione che rendono facile la vita a
questi tizi. Java  lo citavo perché mi è venuto in  mente in quanto da
questo punto di vista di solito reagisce alle "polpette avvelenate" in
un modo  che riduce al minimo i  danni (crepa quel thread  ma il resto
del sistema è salvo).
Altro  discorso.  Tempi  di  risposta  del servizio.  
E' un servizio brevissimo ?  Mi  va bene un solo thread, tanto i tempi
di attesa delle altre richieste non sono un problema. Un loop in VB ce
la fa.
Ma un  servizio che prende  dei dati o  deve ricevere dei file  non ha
queste  caratteristiche,  si  prefigura  come un  servizio  dai  tempi
lunghi.
Arriva  una richiesta  del primo  cliente, si  inizia a  servirla  e a
lavorare con il loop - e  intanto nessuno è il listen sul socket.  Nel
frattempo  arrivano altre  richieste (di  connettersi al  servizio) di
altri clienti che si mettono in coda. Aspettano. Per alcuni clienti la
richiesta  andrà  in  timeout  -  e  quindi niente  servizio  -  o  ne
invieranno una nuova generando un aumento dei problemi...
La soluzione in  questi casi è di mettere  un processo/thread (dipende
da cosa hai disponibile nel S.O. - i thread vanno decisamente meglio e
parlerò  solo di loro)  in listen  sulla porta  del servizio  e quando
arriva  una richiesta questo  attiva un  altro thread  che si  mette a
lavorare per  smaltire la richiesta  mentre il primo thread  ritorna a
fare servizio di "accettazione". (BTW, questo non è una mia creazione,
sono  cose che si  trovano in  letteratura, i.e.  Internetworking With
TCP/IP di Comer, volume 3)
Ora VB  e il multithreading  non vanno proprio  d'accordissimo, quindi
per questo  tipo di servizi VB  non va proprio bene.  Rischi di pagare
più costi di  programmazione di quanto ti sarebbe  costato in un altro
linguaggio e avere risultati meno validi.
W> perche in cobol un compilatore C...ed il PROLOG?!
La  frase  era  un  esempio  tipico  dell'hackerdom.  
   :like kicking dead  whales down the beach: adj.   Describes a slow,
difficult,  and disgusting  process.   First popularized  by a  famous
quote about  the difficulty  of getting work  done under one  of IBM's
mainframe OSes.  "Well,  you _could_ write a C  compiler in COBOL, but
it would be like kicking dead  whales down the beach."  See also {fear
and loathing}.
Un COBOL è  un linguaggio antichissimo al quale  manca (ad esempio) il
concetto di call stack. Ovvero non è lo strumento più adatto a fare un
compilatore.
I giapponesi avrebbero detto "per  l'uomo col martello ogni problema è
un chiodo". 
Ovvero, usa lo  strumento giusto per il lavoro che  devi fare. Ci sono
cose che faccio in VB e non farei in C (il mio linguaggio preferito).


 writes:
MS> Eh, già, scusa, mi sono spiegato male, anche perché il thread sta
MS> lentamente virando verso i confini della mia ignoranza... dove nessun
MS> neurone è mai giunto prima... :-))).
Il mio  neurone è stato portato in  quei luoghi da una  serie di libri
divertenti anche se non economicissimi, Internetworking with TCP/IP di
Comer (credo D. Comer).  L'editore dovrebbe essere Addison Wesley. Gli
esempi sono in C.
 
MS> Pero una volta ho provato ad inviare un file, suddividendolo in n
MS> pacchetti ed inviarlo tramite Winsock ed il risultato è stato pessimo
MS> (senza tener conto della lentezza)...
Non mi piace  molto come è stato impostato  Winsock.  Sei costretto ad
agire in maniera asincrona - d'altro canto o fai così o in VB ti sogni
il refresh dei form. Ho fatto tempo fa un client POP che prelevasse la
posta  mettendomela in  una mailbox  Unix  (uso Emacs  per leggere  la
posta) e  che avesse un po'  di bells'n'whistles tanto  per far capire
che succedeva. Mamma che casino. Ora sono passato ad un programmino in
C  che si  mette nella  traybar e  si basa  su codice  che  ho trovato
distribuito sotto GNU GPL :)...
