Visualizzazione dei risultati da 1 a 4 su 4
  1. #1
    Utente di HTML.it
    Registrato dal
    Nov 2006
    Messaggi
    31

    Sincronizzazione ObjectOutputStream ObjectInputStream

    ciao!

    sapete mica se ObjectOutputStream e ObjectInputStream sono sincronizzati?

    cioè se A invia dei dati in continuazione a B tramite gli stream suddetti,

    ad ogni nuovo invio lo stream di A attente che B abbia letto i dati in ingresso? oppure continua a inviare dati, magari intasando il buffer di B ?

    grazie

  2. #2
    Utente di HTML.it L'avatar di andbin
    Registrato dal
    Jan 2006
    residenza
    Italy
    Messaggi
    18,254

    Re: Sincronizzazione ObjectOutputStream ObjectInputStream

    Originariamente inviato da Codek
    sapete mica se ObjectOutputStream e ObjectInputStream sono sincronizzati?
    Per "sincronizzazione" si intende generalmente tutta la (grossa) questione legata alla "thread safety" e all'uso di uno stesso oggetto in modo "concorrente" da più thread.
    E in tal senso, giusto per la cronaca, queste due classi non sono "thread safe".

    Originariamente inviato da Codek
    cioè se A invia dei dati in continuazione a B tramite gli stream suddetti,

    ad ogni nuovo invio lo stream di A attente che B abbia letto i dati in ingresso? oppure continua a inviare dati, magari intasando il buffer di B ?
    Questo a cui ti stai riferendo non ha nulla a che fare con la sincronizzazione tra più thread "concorrenti". Punto.

    E comunque non hai precisato cosa c'è "sotto". Perché ObjectOutputStream/ObjectInputStream da soli non fanno nulla .... devono avere "sotto" un XXXOutputStream/XXXInputStream.
    Si deduce tuttavia dalle tue parole che si tratta quasi sicuramente di "stream" legati a Socket di "rete".

    E in quest'ottica non è questione di "sincronizzazione" ma piuttosto di "bufferizzazione". E per darti la risposta (finalmente!) finale ... no, non c'è sicuramente quella "attesa" che tu vorresti.
    Se invii un oggetto attraverso ObjectOutputStream esso non si blocca di certo finché dall'altra parte legge l'oggetto.
    Ci sono sicuramente questioni di bufferizzazione più complesse (e che dipendono anche dal S.O.) inerenti lo stack TCP/IP. Ma sarebbe difficile darti dati/informazioni certe, visto che la questione è "vaga".
    Andrea, andbin.devSenior Java developerSCJP 5 (91%) • SCWCD 5 (94%)
    Java Versions Cheat Sheet

  3. #3
    Utente di HTML.it
    Registrato dal
    Nov 2006
    Messaggi
    31
    grazie della risp e delle delucidazioni, si volevo affrettare la domanda cercando di far capire più che altro il senso però ci ho messo degli erroracci...

    ma quindi per evitare un intasamento del buffer devo inviare di volta in volta un ack (un messaggio) che confermi la lettura dei dati ricevuti da B?
    Perchè A invia continuamente informazioni a B (tramite socket) il quale una volta ricevuti, li deve elaborare... e se B è lento a elaborali.. penso che il buffer si possa intasare (anche perchè i dati che invio sono tipo 80Kb al sec)

    magari ci sono delle classi stream che si comportano come il "consumatore e produttore"
    cioè che attendono che il dato sia letto/consumato dal ricevente prima di inviare...

  4. #4
    Utente di HTML.it L'avatar di andbin
    Registrato dal
    Jan 2006
    residenza
    Italy
    Messaggi
    18,254
    Originariamente inviato da Codek
    ma quindi per evitare un intasamento del buffer devo inviare di volta in volta un ack (un messaggio) che confermi la lettura dei dati ricevuti da B?
    Se vuoi "inventarti" un tuo protocollo che prevede un "acknowledge" da parte del ricevente .... beh, nessuno ti vieta di farlo.
    Gli ObjectXXXStream sono anche in grado di inviare tipi primitivi (come i DataXXXStream) pertanto potresti "inventare" il seguente protocollo: A invia un oggetto a B, A quindi resta in attesa di una risposta e B invia un "acknowledge" composto da un byte 0x06 (per non inventarsi chissà quale byte, in ASCII 0x06 significa proprio ACK, Acknowledgment).
    Ma ripeto ... è una possibilità che ho inventato adesso così sul momento .... è solo uno dei possibili scenari.

    Originariamente inviato da Codek
    Perchè A invia continuamente informazioni a B (tramite socket) il quale una volta ricevuti, li deve elaborare... e se B è lento a elaborali.. penso che il buffer si possa intasare (anche perchè i dati che invio sono tipo 80Kb al sec)
    Anche supponendo che il mittente sia così veloce da inviare dati più velocemente di quanto rete+destinatario siano in grado di gestire, comunque non succederebbe nulla di grave ... ad un certo punto la write di un dato si bloccherebbe finchè "qualcosa" si libera. Ovvero non si perderebbe un bel nulla.
    Se uno scenario del genere può andarti bene o no ... devi saperlo tu.

    Originariamente inviato da Codek
    magari ci sono delle classi stream che si comportano come il "consumatore e produttore"
    cioè che attendono che il dato sia letto/consumato dal ricevente prima di inviare...
    No, non c'è nulla. Perché qui si tratta di "networking" e gli oggetti che scrivono da un lato e che ricevono dall'altro lato sono in JVM distinte e non "sanno" nulla dell'altro.
    E oltretutto come funziona il networking (es. per le questioni di buffering) "sotto sotto" nel S.O. non è nemmeno sotto il controllo di Java.
    Pertanto l'unico modo di fare un qualcosa del tipo Mittente-aspetta-che-Destinatario-legga lo puoi solo fare con un "tuo" protocollo che gestisca la cosa a livello più "sopra" del networking TCP/IP.
    Andrea, andbin.devSenior Java developerSCJP 5 (91%) • SCWCD 5 (94%)
    Java Versions Cheat Sheet

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2024 vBulletin Solutions, Inc. All rights reserved.