1

Regular DatagramSocket works fine... ICE4J DatagramSocket seems to truncate data!?

The sending size packet is 2,500 but the receiving end is always 1500 (with regular Java DatagramSocket the receive packet size is the same as the send size).

Receive End:

 Component rtpComponent = stream.getComponent(org.ice4j.ice.Component.RTCP);
 CandidatePair rtpPair = rtpComponent.getSelectedPair();
 videoDS = rtpPair.getDatagramSocket();

In a Thread:

byte[] buffer = new byte[250000000];
final DatagramPacket dp = new DatagramPacket(buffer, buffer.length);
videoDS.receive(dp);
final byte[] clone = new byte[dp.getLength()];
System.arraycopy(dp.getData(), dp.getOffset(), clone, 0, dp.getLength());
final Image image = new Image(new ByteArrayInputStream(clone));

The sending side is pretty much the same except it is run on an Android...

The only difference between non-working code is that the first paragraph is used for Sending and Receiving. If I use a regular Java Socket it will work (but of course not behind routers, which is why I am using Ice4J).

msj121
  • 2,812
  • 3
  • 28
  • 55

2 Answers2

1

I found the prime issue....

See org.ice4j.stack.Connector line 160

/*
* Make sure localSock's receiveBufferSize is taken into
* account including after it gets changed.
*/
int receiveBufferSize = 1500;

The data is CLEARLY being cutoff.... see line 188

packet.setData(
            new byte[receiveBufferSize],
            0,
            receiveBufferSize);
....
localSock.receive(packet); //line 200

My Current solution is to edit the receiveBufferSize to 25000 and the actual packet data is the correct amount. Perhaps I will request to merge.

msj121
  • 2,812
  • 3
  • 28
  • 55
  • The error is yours. You are trying to send an infeasibly large datagram that isn't reliably supported by (a) ICE4J (b) UDP (c) IP (d) Ethernet or PPPoE or whatever your physical layer is. – user207421 Apr 14 '15 at 10:52
  • Do not list to EJP he doesn't understand UDP protocols in Java.... The above fix works and has been committed in GitHub and Approved. – msj121 Apr 14 '15 at 14:37
  • Sadly you are using StackOverflow for your ego and cannot admit that my answer is correct. A fix to the library which un-necessarily requires packets to be 1500 against Java specification. If it truly wanted to enforce this it should fragment the packets (which is of course pointless since Java at the hardware level does this).... – msj121 Apr 14 '15 at 14:42
  • I honestly cannot imagine someone who down votes correct answers for their own ego it is AMAZINGLY SAD.... – msj121 Apr 14 '15 at 14:43
0

The sending size packet is 25,000 but the receiving end is always 1500

You are never going to receive a UDP datagram larger than the path MTU unless:

  • there is no router between you and the target, and/or
  • the datagram didn't get fragmented, or
  • all the fragments arrived at the target.

Otherwise loss of any fragment leads to loss of the entire datagram.

The generally accepted payload limit for UDP datagrams is 534 bytes. Not 25k.

user207421
  • 305,947
  • 44
  • 307
  • 483
  • You are missing the point... With regular Java code all information is processed and transmitted successfully. It is the ICE4J code that needs some work. Finally I added one extra zero, I will fix that. Sadly that is NOT the issue. If there is a limit in ICE4J that should be able to be changed imo, but 1500 does not match 534. – msj121 Apr 12 '15 at 14:58
  • It is you who is missing the point. A fragmented datagram one of whose fragments is lost will never be delivered. 534 ensures there is no fragmentation. Greater than 1500 guarantees it. This is basic TCP/IP, nothing to do with Java or specific software. – user207421 Apr 12 '15 at 21:58
  • Hmmm... As far as I understand datagram packets are fragmented and compiled together and given to the java level or they are skipped entirely ... there is no such thing as only getting fragments in Java http://stackoverflow.com/questions/7931726/are-datagrams-always-received-completely IMO I proved this by using Java to transport and showing there is something specifically in ICE4J causing the issue not the networking limitations. – msj121 Apr 13 '15 at 01:21
  • You've just agreed with me. The packet is either presented intact to Java or not at all. It therefore doesn't begin to make sense to blame a software layer *above* Java. It all happens in the IP and UDP layers. – user207421 Apr 14 '15 at 10:20
  • So why do I get packets that are only 1500? They should be complete or not at all. You make no sense whatsoever.... – msj121 Apr 14 '15 at 14:36