Qualcuno può dirmi quale è più stabile? So che ognuno ha i propri vantaggi e svantaggi. Ma quale è meglio per http, ecc.?Indy o ICS o?
Nella mia precedente applicazione ho usato indy9 ma non ero soddisfatto, perché a volte ricevevo strani errori.
Qualcuno può consigliarne uno?
Io uso Indy in molti progetti. Ho usato entrambi 9 e 10 principalmente come server HTTP e proxy. I progetti ottengono traffico molto intenso a volte (HTTP). Indy non mi ha mai deluso. Funziona molto stabile.
Ma ho anche avuto alcune situazioni "strane" in cui ho dovuto scavare in profondità per trovare il problema sottostante. Inoltre non mi piace il modo in cui Indy tende a gestire un sacco di cose attraverso le eccezioni. In generale mi piace di più lo stile di codifica ICS. Ma lasciami andare a ICS.
ICS utilizza socket non bloccanti, mentre indy utilizza il blocco. Mentre il non blocco è ok e sembra essere a prima vista migliore, l'ho trovato irritante in molte situazioni. Il problema è che il flusso naturale del codice viene perso a causa delle funzioni di callback. Ciò rende più difficile scrivere tipi di librerie procedurali. Inoltre non mi piace come tutto venga gestito attraverso i messaggi. Per me diventa molto veloce quando viene mixato con il multithreading. E il multithreading è mainstream in questi giorni.
Così mentre mi piace lo stile di codifica e la qualità del codice in ICS, preferisco la semplicità di utilizzo e la modalità di blocco di Indy. Quello che ti piace di più dipende da te, ma entrambe le librerie sono mature e stabili.
Questi sono i miei due centesimi.
Ho usato Indy 9 e 10 per TCP, HTTP e FTP con pochissimi problemi. Anche ICS è una buona scelta. Non è bloccante, il che cambierà il modo in cui lo utilizzi.
Non l'ho usato, ma ho sentito cose positive su Synapse, che sta anche bloccando.
Quale è meglio dipende realmente da un caso d'uso specifico, ma non ero soddisfatto di indy come client http e ICS ha finito per essere esattamente ciò di cui avevo bisogno, con molte più stranezze casuali.
Nota che non è bloccante, quindi non è solo una sostituzione.
Uso Indy 9 per codice di produzione stabile, rilasciato, su oltre 1 milione di utenti e non ho mai ricevuto errori strani.
Uso anche Indy e ICS.
La maggior parte delle volte preferisco Indy perché l'implementazione di un tipo sequenziale di protocolli con esso è molto semplice (la richiesta viene eseguita nella propria thread in modo da semplificare la lettura/scrittura sulla connessione). L'utilizzo di Indy richiede una solida conoscenza del threading e della sincronizzazione. Diversamente da Runner mi piace come Indy usi Exceptions per gestire cose "eccezionali" perché mi permette di concentrarmi sul normale flusso del protocollo (io uso i blocchi try-finally per assicurarmi di deallocare le risorse).
Ho anche utilizzato ICS in un'applicazione in cui Indy ha semplicemente fallito: l'ho usato per un'applicazione che implementa un proxy TCP/IP. L'utilizzo di ICS è stato più semplice a causa della sua natura non bloccante. Sono stato in grado di "proxy" di protocolli TCP/IP di cui non so nulla, quindi non ho idea di come i byte passerebbero da un'estremità all'altra. Indy ha fallito in questo scenario perché in Indy stai leggendo l'etere o stai scrivendo, non puoi fare entrambe le cose contemporaneamente.Usare ICS per implementare un protocollo di tipo sequenziale è un po 'di dolore: in pratica è necessario utilizzare la logica dello stato macchina, frenare il protocollo in piccoli bit, tenere le bandiere in posizione in modo da sapere dove ci si trova nel protocollo. Un grande vantaggio: François Piette, l'autore di ICS, è attivo e molto utile su numerosi forum e mailing list ed è molto pronto ad aiutare con qualsiasi cosa relativa a ICS.
Per me, se devo fare qualcosa con TCP/IP, il percorso decisionale è molto semplice: può essere fatto con Indy? Quindi è Indy. Se non può essere fatto con Indy, allora sarà fatto con ICS!
Ricorda che Indy è sempre in fase beta. A volte devi lavorare con build notturne.
Direi che la risposta dipende da cosa si vuole fare con Internet. Indy va bene se sei pronto a essere coinvolto nella comprensione di come funziona, ed è molto capace. ICS è un approccio diverso alle cose e l'ho usato in modo efficace per i sistemi a più connessioni. Ma per le cose tipo "prendi un file o invia un messaggio di posta elettronica" di tipo giorno, dove vuoi svolgere un'attività di base, uso sempre lo Clever Components Internet Suite mentre crei il componente, imposta le opzioni e funziona. La suite è abbastanza completa e riceve aggiornamenti utili.
Testiamo Indy10 IdTCPClient per ricevere lo streaming video dal server remoto, è OK. Ma quando riceve lo streaming, nello stesso tempo lo usa per inviare alcuni dati al server, dopo alcuni minuti, i dati del flusso ricevuto iniziano a perdere byte di dati. Usiamo lo strumento sniffer per tracciare questo problema, ha confermato che IdTCPClient ha perso alcuni byte nel ricevere lo streaming.
Quindi, testiamo Indy9.018, lo stesso problema è successo, ma poche volte VS. Indy 10.
Mentre io favorisco anche Indy, penso che gli exampels di ICS siano superiori. Specialmente Indy10 –
Completamente d'accordo. Indy10 è molto povero sugli esempi. – Runner
@Runner Basta guardare SO ci sono più domande relazionate con problemi di Indy che ICS. Tu sei il giudice che cosa è più stabile. –