Receiving UDP packets on the CRIO

[alexhenning]

Hi,

I've been trying to receive custom data on port 1130, but I am unable to get a connection. When running the following code on the CRIO, it stops after printing "Opening socket connection." I assume the issue is with ss.acceptAndOpen(). It doesn't crash, it just stops at that point.

System.out.println("Opening server socket connection.");
ServerSocketConnection ss = (ServerSocketConnection) Connector.open("socket://:1130");
System.out.println(ss.getLocalAddress());
System.out.println("Opening socket connection.");
StreamConnection sock = ss.acceptAndOpen();
System.out.println("Opening input stream.");
in = sock.openInputStream();

Does anybody no what I'm doing wrong? Has anyone been able to successfully read data off of port 1130 in java.

Thanks for any help.

[sjspry]

A ServerSocketConnection is TCP, not UDP. You'd be wanting DatagramConnection, which is UDP. Open with

Connector.open("datagram://:<port>");

for incoming, and

Connector.open("datagram://<ip>:<port>");

for outgoing (I always thought UDP sockets were bidirectional, but I guess J2ME handles it somewhat differently).

[John Heden]

Greetings,

I'm attaching a working CRIO C++ example function that we managed to get working the other day. I wish I could help in Java but perhaps this example might help. There is some dialog on this on another thread around what we can/can’t do with this new UDP functionality.

John

Related thread:
http://www.chiefdelphi.com/forums/sh...&highlight=UDP

[alexhenning]

I had tried datagram before, unfortunately, when I run it I get:

[frcrun] [cRIO] javax.microedition.io.ConnectionNotFoundException: The 'datagram' protocol does not exist
[frcrun] [cRIO] at javax.microedition.io.Connector.open(245)
[frcrun] [cRIO] at javax.microedition.io.Connector.open(193)
[frcrun] [cRIO] at javax.microedition.io.Connector.open(177)
[frcrun] [cRIO] at org.usfirst.frc348.BreakoutBox.<init>(BreakoutBox. java:29)
[frcrun] [cRIO] at org.usfirst.frc348.JagBot.<init>(JagBot.java:24)
[frcrun] [cRIO] in virtual method #11 of com.sun.squawk.Klass(bci=53)
[frcrun] [cRIO] at com.sun.squawk.imp.MIDletMainWrapper.main(99)
[frcrun] [cRIO] in virtual method #95 of com.sun.squawk.Klass(bci=25)
[frcrun] [cRIO] at com.sun.squawk.Isolate.run(1506)
[frcrun] [cRIO] at java.lang.Thread.run(231)
[frcrun] [cRIO] in virtual method #47 of com.sun.squawk.VMThread(bci=42)
[frcrun] [cRIO] in static method #3 of com.sun.squawk.VM(bci=6)

Is there something different about the version of J2ME running on the CRIO?

[derekwhite]

Which protocols are supported aren't standardized in CLDC. Java on the cRIO supports socket:, serversocket:, and file: protocols currently. Unfortunately it doesn't support datagrams yet.

[alexhenning]

Thanks for the info. That's very very annoying, do you know if there are any plans to add support for it. We were going to take advantage of the UDP ports for a custom dashboard and breakout box, but we'd rather stay in java.

[sjspry]

If you read team update #5 it mentions a TCP port you can take advantage of, it's currently what I'm using. There's really no good reason to be using UDP, seeing as communications are so close (it just ends up making things more complicated, but whatever).

Oh, port should be 1180, just remembered.

[Tom Bottiglieri]

Originally Posted by sjspry

There's really no good reason to be using UDP, seeing as communications are so close (it just ends up making things more complicated, but whatever).

Wouldn't that be a better reason to use UDP? If there's less of a chance of dropped packets, why bother with the added overhead of TCP?

[sjspry]

Originally Posted by Tom Bottiglieri

Wouldn't that be a better reason to use UDP? If there's less of a chance of dropped packets, why bother with the added overhead of TCP?

Because the "overhead" of TCP is barely noticeable (the information density is ~94%, with ~6% left for headers) and really only comes into play when you have a noisy connection, where packets would be missed and therefore resent, and during the initiation of a connection, which you do once. Dropped packets are a non-issue, as well, and wouldn't affect TCP's performance. It happens, but very rarely (comparatively) and in everything I've experienced it's rarely anything but hardware problem.

Besides apparently not being able to use UDP, TCP is generally easier to use, as a stream, than to have to fit everything into a fixed datagram and then unpack it (this is more of a personal choice, though). The only benefit of UDP will be if you are sending time sensitive information, otherwise I see no reason why it would be chosen to use.

It doesn't matter either way. You can do some time tests with TCP vs UDP, if you want.

[alexhenning]

I was planning on using the camera too, which according to the update is used by the camera. Also, I control data is time sensitive, so UDP seemed sensible.

[AlexBrinister]

I was looking at the WPILib/CLDC very carefully recently and I noticed that there is a package called com.sun.cldc.jna that specifies several classes to allow for calling native functions from Java. I was wondering if one could make use of vxWorks UDP functions and implement a UDP communication class using native vxWorks calls. I notice that this is what WPILib essentially does with functions like FRC_NetworkCommunication_JaguarCANDriver_sendMessa ge and FRC_NetworkCommunication_JaguarCANDriver_receiveMe ssage. It appears that this is almost like extern'ing in C/C++.

Alex Brinister

[NotInControl]

This might be obsolete, as next year Java teams are no longer constrained to Java ME, and can use the full power of Java SE (which supports both TCP and UDP) on the RoboRio.

Don't think it is fruitful to attempt to add functionality to the current system since it will be phased out next season.

Hope this helps,
Kevin