Skip to main content
Participant
July 10, 2013
Answered

TCP in a native extension

  • July 10, 2013
  • 1 reply
  • 904 views

I have tried to contact a developer named Wouter Verweirder regarding my work based on his native extension, but have been unable to reach him.  His UDPSocket native extension is found here:

https://github.com/wouterverweirder/AIR-Mobile-UDP-Extension

I hope that someone here can help me regarding this inquiry:

I have reasons for writing a native extension like his, but for TCP communication rather than UDP.

I am very familiar with both UDP and TCP networking at the packet level, as well as at the source code level in several languages.  I have replaced his UDP components with their TCP counterparts as appropriate, but I get no communication at all.

To start from square one, I first made sure I was able to build his extension from the source code, and then use the resulting ANE with my Android app for UDP communication as he originally intended.

Then, I simply added the following as a test at the end of his UDPSocketAdapter constructor (in red):

     public UDPSocketAdapter(UDPSocketContext context) {

          this.context = context;

          this.hasSentClose = false;

          try {

               channel = DatagramChannel.open();

               channel.configureBlocking(true);

               socket = channel.socket();

          } catch (SocketException e) {

          } catch (IOException e) {

          }

          theReceiveQueue = new LinkedBlockingQueue<DatagramPacket>();

          try {

               Socket tsocket = new Socket("192.168.2.23", 8137);

               OutputStream outStream = tsocket.getOutputStream();

               byte[] data = {'h','e','l','l','o',' ','w','o','r','l','d'};

               outStream.write(data);

               outStream.flush();

               outStream.close();

               tsocket.close();

          } catch (IOException e1) {

               Log.put("i/o exception:\r\n" + Log.stack2string(e1) + "\r\n");

          }

     }

(Of course, I also imported the Socket and OutputStream classes.)  After I rebuild the ANE and then rebuild and run my app, not only do I not see my test TCP traffic in my sniffer, but all of his UDP functionality which was previously working, is now broken and I have zero UDP communication!

The line of code in my catch block sends nothing to my log file (via my Log class), so I know my test code is not generating an exception.  (In fact, my test code works fine in another fully native Android app.)

Have I just missed something fundamental?  I appreciate any suggestion anyone might have.

Thank you.

This topic has been closed for replies.
Correct answer 3urodud3

Finally I have determined that the Socket object must be instantiated in a worker thread, and then TCP connections succeed.

For some reason, if any attempt is made to instantiate the socket in the main thread, all network communication of any kind from the native extension breaks.

I have no good idea why this would be an issue for TCP, but not for UDP, as evidenced in the working UDP native extension on which I am basing my work, which instantiates a DatagramSocket in the main thread with no problem.

I suspect that it has something to do with the connection-oriented behaviour of TCP, and the three-way client/server handshake that happens immediately when a Socket object is created.  Because the absence of this in UDP is the only functional difference between the two cases.

Maybe someone with a deep understanding of AIR native extensions has more specific information.

1 reply

User Unknow
Legend
July 10, 2013

Did u know that air support udp and tcp on ios and android on latest betas?

http://labs.adobe.com/technologies/flashruntimes/air/

3urodud3Author
Participant
July 11, 2013

Thanks for your reply, Anton.  But of course I know that, since they have been in there a long time now.

The UDP support is limited on mobile platforms, and I use Wouter's native extension because I need broadcast functionality.

For TCP, as I mentioned, I have reasons for doing it in a native extension, specifically to avoid performance problems I am seeing (with AIR's Socket class) when my app is sent to the background.

3urodud3AuthorCorrect answer
Participant
July 26, 2013

Finally I have determined that the Socket object must be instantiated in a worker thread, and then TCP connections succeed.

For some reason, if any attempt is made to instantiate the socket in the main thread, all network communication of any kind from the native extension breaks.

I have no good idea why this would be an issue for TCP, but not for UDP, as evidenced in the working UDP native extension on which I am basing my work, which instantiates a DatagramSocket in the main thread with no problem.

I suspect that it has something to do with the connection-oriented behaviour of TCP, and the three-way client/server handshake that happens immediately when a Socket object is created.  Because the absence of this in UDP is the only functional difference between the two cases.

Maybe someone with a deep understanding of AIR native extensions has more specific information.