• Regolamento Macrocategoria DEV
    Prima di aprire un topic nella Macrocategoria DEV, è bene leggerne il suo regolamento. Sei un'azienda o un hosting/provider? Qui sono anche contenute informazioni per collaborare con Sciax2 ed ottenere l'accredito nella nostra community!

Guida Socket-SendFile

Comunque, in riferimento alla tua affermazione, perché dici di preferire un server in C++ e un client in un altro linguaggio? Non puoi farli entrambi in C++ o entrambi in C o entrambi in Java?

Perché quando qualcuno ti chiede "in che linguaggio hai scritto il server ?" io risponderò sempre che l'ho scritto in C++. E' un capriccio il mio, se poi ho delle particolari esigenze tanto meglio.

la teoria da applicare per comunicare rimane pressochè simile. Certo la gestione dei thread è diversa ma il ragionamento sul trasferimento è uguale.

Ne sono consapevole, sta di fatto che come linguaggio non mi ha mai appassionato.

Ma comunque a me Java non piace molto per una questione di sintassi soprattutto.

Credo che più per la sintassi sia una questione di classi, alcune classi sono davvero strane con nomi altrettanto strani. Sarà che sono troppo abituato col .NET :soso:
 
  • Like
Reactions: 1 person
@System32
il fatto che ti appassioni o meno è soggettivo. Tra l'altro non trovo nessuna classe/interfaccia con nomi inappropiati. :soso:
 
@System32 il nome è più che adatto , dato che tale classe fa parte di java.util e non centra niente con java.lang.string o stringBuilder , infatti come Vector o l'obsoleta classe stack implementa l'interfaccia Enumeration , quindi lo StringTokenizer è simile a uno scanner di stringhe e non alla classica funzione split del .Net, Sono argomenti completamente separati :soso:.
Tale classe è anche alla base del processo del processo noto come lexer.

Comunque è tutta questioni d'abitudine per la sintassi. Soprattutto se inizi a suddividere per package, i nomi non risulteranno tanto strani
 
Potremmo stare qui ore a disquisire se sia meglio Java o C++, secondo me sono due ottimi linguaggi che ti forniscono due alternative diverse per risolvere un medesimo problema. Non conosco bene il C++, ma Java è molto preciso e potente. Vero è che è molto poco intuitivo e spesso maccheronico nei lunghi nomi delle sue Classi, però una volta che incominci ad orientarti all'interno dei vari StringTokenizer riesci davvero a pedalare veloce.
 
Se si vuole di qualcosa di "buono" e semplice, punto al Java. Se voglio qualcosa di potente ma difficile punto al C++. Le differenze ci sono, ed il java non potrà mai eguagliare la potenza del C++.
 
Ho trovato il codice molto lungo e poco efficiente, ho realizzato quest'estate un applicazione che utilizzava le socket e anche lo scambio dei file in entrambi le direzioni Server/Client tramite il Protocollo TCP/IP e ho scritto 1/4 delle tue righe di codice.
In più non utilizzando il buffer si ha una riduzione di velocità per certe dimensioni di alcuni file
 
Ho trovato il codice molto lungo e poco efficiente, ho realizzato quest'estate un applicazione che utilizzava le socket e anche lo scambio dei file in entrambi le direzioni Server/Client tramite il Protocollo TCP/IP e ho scritto 1/4 delle tue righe di codice.
In più non utilizzando il buffer si ha una riduzione di velocità per certe dimensioni di alcuni file

è lungo perché suddivide le operazioni in thread, poco efficiente non direi dato che con piccole modifiche potresti trasferire testo e file contemporaneamente.
se hai scritto 1/4 delle righe che ho scritto io , significa che non supporta il multiThreading
ho utilizzato buffer per il trasferimento dei dati , invece per la scrittura dei file no , volendo potevo fare la stessa cosa. Ma era solo un esempio
 
Ultima modifica:
Utilizza il multithreading ma soprattutto permette di avere più connessioni in contemporanea... mi spiace deluderti
 
Utilizza il multithreading ma soprattutto permette di avere più connessioni in contemporanea... mi spiace deluderti

allora il codice è più complesso di quello mostrato :soso: , d'altronde non potrebbe essere 1/4 di questo come affermato in precedenza. dato che gestisce la multiconnessioni e presumo che suddividi le richieste in liste per gestirle più facilmente ^^
 
Ultima modifica:
Il codice è uno e vale per ogni connessione essa è indipendente dall'altra, tra l'altro ho realizzato anche un client Android che si connette al server in Java. Vi assicuro che il codice che ho utilizzato è semplice e molto corto ma efficace. L'app è anche pubblica su alcuni store e funziona alla grande, ovviamente non può competere con teamviewer anche perchè per il momento ho utilizzato una connessione diretta e connessa utilizzando il protocollo TCP/IP ma più avanti la rifarò con il protocollo UDP