Socket DatagramSocket, wieviele Packete sind in der Receive Queue?

[Experimental]

Hi@all,
bin gerade neu hier im Forum. Habe ein Problem beim Programmieren mit Java wo ich auch beim Google noch keine Lösung gefunden habe.

Also ich habe eine Java Application unter Linux (Kernel 2.6) die einen UDP Datenstrom empfängt, die eingehenden Packete verarbeitet und dann wieder weiter schickt auch als UDP Packete. Hatte nun schon ein paar mal das Problem das der eingehende UDP Strom den ReceiveBuffer zum Overflow gebracht hat und die Application dann neu gestartet werden muß. Das möchte ich nun damit abfangen das wenn der SocketBuffer eine bestimmte Anzahl an Packeten in der Queue hat einen Flush auf die Queue macht. Das passiert normalerweise nur wenn bei einem Playback die Datenrate der UDP Packete nicht richtig gesetzt wurde.

Die UDP Buffer habe ich über Proc FS bereits auf 40MB gesetzt.

Habe bisher noch keine Möglichkeit in Java gefunden herauszufinden wieviele Packete sich im Socket Puffer befinden. Mit der Funktion 'getReceiveBufferSize()' bekomme ich ja nur zurück was das OS bereit stellt.

Hoffe das es dafür eigentlich eine relative triviale Lösung geben sollte .

MfG
Jens

 

[Kr0e]

Ähm, habe mich lustigerweise gestern mit UDP Buffersizes beschäftigt, obwohl ich das letzte Mal mit UDP knapp vor 2 Jahren gearbeitet hab, also ein lustiger Zufall!

Meines Wissens kannst du nicht über Sockets herausfinden, wieviele Pakete in der "Queue" sind. Diese Queue ist auch nicht wirklich eine Queue, sondern einfahc ein Buffer und wenn der voll ist, werden Pakete gedroppt.

Sprich wenn du sagst dein UDP Socket hat einen Puffer von 8192, so werden nur Pakete abgenommen, s.d. dieser Puffer nicht voll ist.

Ich verstehe uach nicht wirklich was dein Problem ist und wozu du iwas flushen willst. Receive einfahc UPD Pakete, verarbeite sie und empfange das nächste. Wenn nun schneller gesendet wird als empfangen/verarbeitet wird, so ist das ein generelles und somit konzeptionelles Problem. UDP ist eben unsicher, was Reihenfolge etc angeht. Sprich Es können sowieso mal Pakete schon beim Transport selber verloren gehen und doppelt oder gar nicht ankommen.

Sprich du müsstest ein gewisses Sicherheitskonzept selbst programmieren (ähnlich TCP), wobei dann der Vorteil von UDP weg wäre und du sowieso direkt TCP nehmen könntest.

Vlt. solltest du nochmal in Ruhe erklären was genau du wilslt

Gruß,
Chris

 

[Experimental]

Also wie es sich mit UDP verhält ist mir schon klar. Und auch das droppen von Packeten ist nicht mein Problem hier.

Nur wenn mein Ausgangs-Stream langsamer ist als der Eingangs-Stream (aus welchem Grund auch immer...) kann ich über netstat -uantp sehen wie die Recv-Q sich bis zum Maximum füllt. Wenn die Queue dann voll ist liest die Application nicht mehr vom DatagramSocket und ich muß die Application neu Starten.
Das versuche ich eigentlich zu verhindern.

Gruß Zurück,
Jens

 

[Kr0e]

Komishc, wieso musst du die App neu starten ? Das hab ich noch nicht ganz verstanden. Wenn die Queue voll ist, werden doch einfahc nur ankommende Pakete gedroppt und das führt doch ansich nicht zum Absturz.

UND: Mit der Berkley Socket API hast du meines Wissens keinen Zugriff auf solche Informationen.

 

[irgendjemand]

@TO

sorry .. aber warum deine app angeblich crashen soll nur weil irgend n buffer VOLL ist und vom OS alles weitere verworfen wird ... das habe auch ich noch nicht ganz verstanden ...

klar gibt es möglichkeiten einen net-stack zum overflow zu bringen ... aber in der regel blockiert das OS selbst sowas da es vorher schon anfängt pakete zu droppen ...

und wie bereits erwähnt müsstest du wenn das so kritisch ist selbst die pakete in die richtige reihenfolge bringen und multiplex und loss selbst erkennen ... wesshalb du dann auch TCP nehmen könntest ...

vllt postest du mal etwas code das man sich mal angucken könnte wodurch dieser angebliche crash verursacht wird ...

WENN deine app irgendwann nicht mehr weitermacht ... dann liegt es mit sicherheit daran das du selbst irgendeine art overflow programmiert hast ... aber daran das zu viel datenmüll via UDP kommt welcher eh vom OS verworfen wird wenn der buffer voll ist ... sorry ... aber das kann ich mir bei java einfach nicht vorstellen

 

[SmartAss]

Hallo,

ich habe ein ähnliches Problem.

Ich habe eine Gerät, welches über UDP angesteuert wird.
Ich muss also ein Kommando als UDP Paket schicken und bekomme einer Response.

Ich habe keinen Receive Thread programmiert, sondern will nur einzelne Pakete empfangen. Also so:

socket.send(packet);
buffer = new byte[UDP_BUFFER_SIZE];
packet = new DatagramPacket(buffer, buffer.length);

socket.receive(packet);

Nun kann es vorkommen, dass mehrere Responses eingelaufen sind. Damit kommt meine Auswertung natürlich durcheinander, weil ich zu dem gesendeten Kommando eine alte Response interpretiere.

Meine Lösung ist es den Socket vorher solange zu lesen bis er leer ist. Unglücklicherweise, geht das nur indem ich auf eine Exception warte.

// clear the input of socket
try {
for (int readCycles = 100; readCycles > 0; readCycles--) {
// receive all packets until socket.receive throws
// SocketTimeoutException
socket.setSoTimeout(1);
socket.receive(new DatagramPacket(new byte[socket.getReceiveBufferSize()], socket.getReceiveBufferSize(),
new InetSocketAddress(this.ipString_, this.portNumber_)));
}
} catch (SocketTimeoutException e) {
// input queue is cleared
logger.trace("message queue cleared");
}

Für alle die es sich nicht vorstellen können, aber es gibt solche Anwendungsfälle.
Meine Frage ist also, wie kann ich prüfen ob Daten eingegangen sind ohne ein .receive() aufzurufen und auf die Exception zu warten.

Ich möchte auch keinen extra Thread implementieren! (wenn möglich)

Danke im Voraus.