2011-12-08 22 views
5

Ho un programma Java che invia costantemente dati UDP da un sistema esterno.Come "cancellare" il buffer di ricezione su un DatagramSocket Java?

Periodicamente, è necessario interrompere la ricezione dei dati (perché un'altra macchina lo sta gestendo). In quei momenti, il thread del mio socket reader entra in un loop del sonno. Quando è il momento di iniziare a ricevere i pacchetti, vado nuovamente in socket.receive(Packet) e ho un buffer pieno di pacchetti che dovrei non essere manipolazione. (I dati sono arrivati ​​nel "tempo di arresto".)

C'è un modo per cancellare il buffer di un DatagramSocket?

In caso negativo, qual è la migliore alternativa? Impostare la dimensione del buffer su 0 quando vado nello stato di attesa e riportarlo quando riavvio i pacchetti di servizio? Chiudo la presa quando io mentre aspetto e ne apro una nuova quando torno?

risposta

4

Anziché avere tempi di inattività sul socket, avere il tempo di inattività su qualsiasi codice elabora i pacchetti.

Quindi il socket continua a ricevere normalmente, ma se è in downtime, rilascia immediatamente il pacchetto.

Non esattamente la soluzione più efficiente, ma è davvero facile da implementare e potrebbe essere utile in quanto lascia il nodo aperto in altri casi per accettare diversi tipi di pacchetti in momenti diversi.

+0

Mi piace. La macchina ottiene comunque i dati e l'effettivo socket-IO è abbastanza economico in confronto (se fatto correttamente :-). Tuttavia, sembra che questo potrebbe ancora portare a condizioni di gara con "stop time" e "altra macchina" a meno che non ci fossero informazioni aggiuntive nei pacchetti per determinare chi dovrebbe gestirli ... –

+0

@ pst assumendo che i pacchetti abbiano qualche tipo di identificare le informazioni su di loro, quindi qualunque segnale spenga dovrebbe essere in grado di dirgli "non accettare pacchetti dopo id 1400000" o qualcosa del genere. Questo ha l'ulteriore vantaggio di avere 1399999 elaborato anche se viene ritardato e raggiunge i nodi dopo che il segnale di uccisione viene colpito. – corsiKa

+0

@ pst Sì, c'è quella condizione di gara. Fortunatamente, la commutazione avviene molto raramente (fa parte di un cluster e viene attivata quando il primario è inattivo e dobbiamo andare al backup a caldo). È accettabile perdere un po 'di dati durante quei tempi (non è richiesta la correttezza esatta, ma vogliamo mantenerla il più accurata possibile e sicuramente non vogliamo contare troppo). –

Problemi correlati