UDP receive

Similar Questions

• UDP receive default buffer size

  Hello

  I have a question about receiving data via UDP:

  Description of the problem:

  An application of part 3 is extract to a PACS + 2400 Hz measurement data.

  All samples are then sent to a UDP port locally.

  I then use a labview application to read the data and perform a treatment.

  The question is, at 2400 Hz I loose a lot of UDP packets because of receive buffer overflow, i.e. new data appear before all the old data is read.

  It's BI data ' in irregular bursts, 10 - 20 times every second.

  I tried increasying the Protocol UDP receive buffer according to this size:

  http://digital.NI.com/public.nsf/allkb/D5AC7E8AE545322D8625730100604F2D

  And it seems to fix the problem.

  But here is another question:

  If I change the size of the UDP buffer during execution of the application of the 3rd part, the 3rd team application will crash.

  So my question is:

  Is it possible to change the value default UDP receive buffer size in windows?

  Such that when the UDP connection is open, it will have a buffer size of 32768 for example, regardless of which application that accesses the UDP connection first?

  Y at - he got another code inside your task of reading as a ms of waiting? Is the task of reading as lean and mean as possible? When you increase the size of the buffer?

  I found this registry key. It may be worth a try. The post was old, it cannot apply to Win7.

  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Afd\Parameters \DefaultReceiveWindow (REG_DWORD) = 16384 (decimal)

• "UDP receiver.vi" does not work on the type of "public" network but on a private type and the field. Why so much?

  I have a configuration Ethernet with 'UDP sender.vi' and "UDP receiver.vi" basically back in as the eponymous example shipped in LabVIEW examples i.e. pair. Nothing special and quite basic.

  The UDP sender regularly sends out UDP (30 bytes) packets to the receiver using the number of receivers IP and port 80. However, the port number is not interest to the problem.

  The sender and the receiver are different machines, but the two LabVIEW 2011sp1/32, Win7/64
  If it is running on a domain network, it works very well. If it runs on a 'public' (Windows Firewall terminology) using the network - IP number data comes through in the Receiver.vi 'UDP '!

  I checked what is obvious:

  1. The packets arrive actually in the network interface (checked with Wireshark) UDP receiver computers. For example. Connection via the sender's public network and firewall it meets on his way there.
  2. firewall on the receiver PC is open for incoming traffic on port 80 for the public (and private + domain name) and open for all programs and allowing the crossing side (there is a router with NAT translation upstream). We even tried to disable the firewall completely - no change.
  3. A program with a similar function as ' UDP Receiver.vi ' but written in C++ running in the same exact state, works as expected.
  4. same "UDP Receiver.vi" running on a target RT (sbRIO9606 or cRIO9024) and off the coast of the exact same cables copper - works as expected.
  5. It is tested on several PCs with the same results.

     For example. everything is, as far as I can see, according to the 'books', and again, I must have missed at least one book. The data arrives in the PC network stack - otherwise the program c ++ would work either. So what is done differently in LabVIEW?

  Any suggestions as to why a C++ program or a RIO can read the 'public' port UDP, but such a LabVIEW program cannot? And especially what can be done to solve it.

  Thank you
  Henning

  There are many other services that is blocked by nature in Windows when you use a network connection of type 'Public '.  Have you added an exclusion for LabVIEW so LabVIEW is not blocked when using a network of type "Public"?

• Receiving UDP does not receive messages

  Hello. I have problem with UDP receiver.

  I can receive messages from the same port you write.

  Stream: open vi--> vi--> read vi UDP UDP writing.  Transmitter and receiver usinf th test port.

  When I try to use vi UDP listen port to just read, I get all the data.

  Program flow. I use vi to send the command on the serial port to MCU. Answer MCU return by sending data to the network port using UDP.

  I start vi to listen to a port UDP (see attached), then I sent the order to MCU. I can see the response on Wireshark, but UDP vi does not receive anything.

  I checked the IP address. Lokks all the same. IP address of the PC and decice is the same as when I write and read at the same time. Any other port.

  Any help please.

  Is the port that you want to use to open? For safety that many IT services will be blocked in ports that don't think they are necessary, or don't want to use.

• Increase the packets received per second UDP

  I have a very high packages (over 100,000 packets per second) rate which I'm trying to capture in LabView.  I configured a single loop to form the loop 'UDP receive' that takes the data from the wire and updates these data in a queue to be processed by another loop.

  The problem is that if I use the builtin UDP receive functions, or one library implementations available OCAP, I will always drop packets.  When the receive loop running I have the time I find it runs only in the range of milliseconds rather than the necessary<10us.  if="" i="" remove="" the="" 'enqueue'="" call,="" and="" do="" nothing="" except="" receive="" the="" data="" and="" increment="" a="" packet="" counter,="" it="" is="" still="" no="" where="" near="" meeting="" timing. ="" this="" leads="" me="" to="" believe="" that="" the="" problem="" is="" with="" the="" amount="" of="" time="" it="" takes="" to="" call="" the="" vi="" to="" perform="" the="">

  Until I write a dll to perform multiple readings of package and transfer the pads of large size to labview, is there something that can be done in labview to increase the rate of packets?  Note that I have captured these data in wireshark on the same computer, and it's more the enough to capture all the data, so it is possible.

  Attached are two examples that do not work because the loop execution rate is too low.  Exactly why the loop runs too slowly is a mystery to me.  Note the "OCAP" version uses the library from the mentioned thread previously.

  The problem is now resolved.  I've updated the dll from this thread to include a "multi-package-group" function that provides in bulk packages to labview.  Even after doing this, I noticed that there was always a bottleneck when LabView went to assemble the packets (data collection of several packages to more large data sets).  This was solved by moving some of the manipulation of specific project data in the dll as well.  When I have free time, I also plan on accounting for the new library in this same thread of OCAP.

• Convert string received UDP a real por

  Hola.

  Estoy con of UN PLC comunicando Labview mediante UDP. Can mandar back values Oyster desde el PLC y worm data in Labview. El problema that are quite en modo don't string y no muy entendibles. He convertido Los has an array of 8 bytes there is Fri is datos numericos, pero no ahora juntar esos 4 bytes can para formar el dato life en nuevo. Sabe alguien como convert esos datos?

  Gracias y a greeting.

  Normal 0 21 false false false ES X-NONE X-NONE / * Style Definitions * / table. MsoNormalTable {mso-style-name : « Table Normal » ; mso-tstyle-rowband-taille : 0 ; mso-tstyle-colband-taille : 0 ; mso-style-noshow:yes ; mso-style-priorité : 99 ; mso-style-qformat:yes ; mso-style-parent : » « ;" mso-rembourrage-alt : 0 cm 5.4pt cm 0 5.4pt ; mso-para-marge-haut : 0 cm ; mso-para-marge-droit : 0 cm ; mso-para-marge-bas : 10.0pt ; mso-para-marge-gauche : 0 cm ; ligne-hauteur : 115 % ; mso-pagination : widow-orphelin ; police-taille : 11.0pt ; famille de police : « Calibri », « sans-serif » ; mso-ascii-font-family : Calibri ; mso-ascii-theme-font : minor-latin ; mso-fareast-font-family : « Times New Roman » ; mso-fareast-theme-font : minor-fareast ; mso-hansi-font-family : Calibri ; mso-hansi-theme-font : minor-latin ;}

  Hola Allende,

  None are las UDP functions you manden don't string como tal, sino're una manera los datos en binario than estan por el puerto UDP receiving computers. ES decir, what what llega a las functions son chorros Wicks as los agrupa en packages of 8-bit y represents esos en Código ASCII 8 bits. Para ver el number en life, you have that esos bits in a stupid number the structure of life number convert. ESTOS envio you links that you will be of mucha para UN formato a los bits right simplice utility:

  http://sine.NI.com/DevZone/CDA/EPD/p/ID/668

  http://digital.NI.com/public.nsf/allkb/FAEE0A6ECD0E987B86256EA900638678?OpenDocument

  http://decibel.NI.com/content/docs/doc-4105

  http://zone.NI.com/DevZone/CDA/EPD/p/ID/2588

  Salu2,

• UDP playback does not work on a real-time target

  Hello

  I am running LabVIEW RT 8.6.1 on a PXI 8106 RT controller.  LabWindows/CVI for RT 9.0.0 execution engine is also installed that I develop using LabWindows/CVI 9.0.  I'm trying to send some data UDP for an external PC via the network for software running on the controller, but this does not work.  The UDP packets are certainly get sent (I receive on my PC when the transmitter to reconfigure my PC IP address) but the UDP callback function is not called.  The call to CreateUDPChannelConfig returns OK.  Here's the (very simple) code that I wrote based on the example of reading NI UDP:

  #include 
  #include 
  #include 
  
  // Global variables
  static int reader_channel = 0;
  
  // Global functions
  int CVICALLBACK UDPCallback (unsigned channel, int eventType, int errCode, void *callbackData);
  
  /// HIFN The main entry-point function for the Real-Time DLL.
  void CVIFUNC_C RTmain (void)
  {
      int errno;
  
      if (InitCVIRTE (0, 0, 0) == 0)
          return;    /* out of memory */
  
      // Create UDP receive task
      errno = CreateUDPChannelConfig(49152, UDP_ANY_ADDRESS, 0, UDPCallback, NULL, &reader_channel);
  
      while (!RTIsShuttingDown ())
      {
          SleepUS (1000);
      }   
  
      CloseCVIRTE ();
  }
  
  int CVICALLBACK UDPCallback (unsigned channel, int eventType, int errCode, void *callbackData)
  {
      static int udp_received = 0, default_rx = 0;
  
      switch (eventType)
      {
          case UDP_DATAREADY:
              udp_received++;
              break;
          default:
              default_rx++;
              break;
      }
  
      return 1;
  }
  

  All that happens is that software is just waiting for the callback to be called (which never does).  I found this ad that described a similar problem, but the developer was using LabVIEW and although he has found a way round the problem, he was never heard as to why it worked.

  Thank you

  Martin

  Hey,.

  Although the problem is now resolved, I thought that put the code for others see if the same error is encountered. The modified code is tested and works. It is saved as an attached png file.

• Help the analysis of UDP packets

  Hello, I am new to Labview and working on a program to read the UDP packets. I was looking at the example UDP receive Labview and read also older messages. The data consists of 1-Header Word (32 bits), 24-data words (each word is 32 - bits), and the rest of the data is data filling which is all zeros. Each package is the same size.  Far by the UDP Receiver.vi example I am able to receive the data and could probably push on with what I have, but I would like to know if there is an easier way to analyze a UDP data packet? I have read others who used a Cluster and the TypeCast but can't seem to make it work. When I try to connect to my Cluster until the TypeCast it wire goes to the dotted line.

  If anyone has any suggestions on the easiest ways to analyze a UPD packet please let me know.

  Thank you

  Joe

  
  

• RT file IO and IO priority network

  I have a Subvi that receives UDP packets and apply a time stamp to each.  The Subvi is defined on the system of execution of data acquisition (LabView RT) and high priority.  This UDP receiver puts data in a RT FIFO.

  I have an another sub - VI, which sets up a TDMS file (creates and adds properties of channel etc.) which is called at the start of the acquisition.  The Subvi is the priority normal, and on the standard runtime system.  Another Subvi runs the RT FIFO in the TDMS file on the same system of execution of normal priority.

  When installing TDMS VI runs for the first time, there is a significant delay in the UDP VI that causes a number of backup packages in the Protocol UDP receive buffer (which causes a flurry of timestamps that are incorrect).

  What can I do to receive the Protocol UDP Subvi didn't get interrupted?  It seems that the Protocol UDP receive function itself may not run at the priority of the Sub - VI that calls it.  But I don't know why.

  The other oddity is that after the first performance of received UDP Subvi, he can run again with no apparent effect on the Subvi the UDP receiver (even if it does the same thing).

  Thank you

  XL600

  Answered my own question.  Trace RT Viewer is your friend!  I had a FGV the priority value subroutine that was blocking the high-priority UDP receive Subvi which took place to run in the same thread, but only in the first inning through the VI.  Go figure...

  Note for later...  Look at these priority settings!

• Lose packets using winpcap

  Hello

  I'm working on a LabVIEW application to view our telemetry data.
  These data are sent over ethernet using UDP and has a payload of 1 332 bytes. The framerate is 6720 packets per second.

  To work with this data rate I put sockets UDP receive exactly the size of the packets multiplied with the payload buffer ( http://digital.ni.com/public.nsf/allkb/D5AC7E8AE545322D8625730100604F2D ). Increasing or decreasing the buffer will lead to errors and one or several packages will be lost.

  However, I'm still a few packages.

  Now, I tried to use the Ethernet Packet Sniffer example ( http://zone.ni.com/devzone/cda/epd/p/id/2660 ) and changed the Example.vi to verify our internal counter of packets in each package. I was happy to see that no packets were lost! But, after adding the VIs Sniffer to my request for loss of massive packets occurs. :-(

  Then, I moved the acquisition work in the wrapper DLL. The function below is called with a 1 d of pre-initalized channels table. The allocation of memory in this way is done in LabVIEW.

  / * LabVIEW created typedefs * /.
  typedef struct {}
  dimSize of Int32;
  LStrHandle LString [1];
  } TD1;
  typedef TD1 * TD1Hdl;

  EXTERNC EXPORT int32 lvwpcap_read_n_packets (uInt32 pcap,
  uInt32 * tv_sec;
  uInt32 * tv_usec;
  uInt32 * capture_len,.
  TD1Hdl capture_data)
  {
  struct pcap_pkthdr * header;
  const u_char * data;
  Int32 array_size, string_size, i.;
  Int32 retval = 1;
  Int32 errors.
  LStrHandle TempString;

  Errors = 0;
  ARRAY_SIZE = (* capture_data)-> dimSize;
  TempString = (* capture_data)-> LString [0];
  string_size = (* TempString)-> cnt;

  * tv_sec = array_size;
  * tv_usec = string_size;

  for (i = 0; i< array_size;="" ++i)="">

  retval = pcap_next_ex ((pcap_t *) OCAP & header, &data);)

  If (retval > 0) {}
  * tv_sec = header-> ts.tv_sec;
  * tv_usec = header-> ts.tv_usec;
  * capture_len = header-> Caron;

  TempString = (* capture_data)-> LString [i];

  avoid the expensive memory allocation.  assumes that the string is at least 64K
  (or whatever it is we set the size max with our init call.
  memcpy (LStrBuf(*TempString), data, header-> Caron);
  }
  else {}
  i-- ; In the case of timeout right pointer to avoid skipping entries in the table
  Errors ++;
  If (error > = array_size) {}
  Returns - 1;
  }
  }
  }

  * tv_usec = errors;
  Return retval;
  return errors;
  }

  The problem: I have also now lose packets! Not on every call to this function, but in a way regularly (in on every third call).
  What am I, am I doing wrong to acquire say 800 packages at once without losing a single?

  Is there anyone with the same problems using winpcap?

  UDP packets are sent by our material and the PC is connected directly via a crossover cable.
  I'm using LabVIEW 8.5 and WinPcap 4.1.2.

  Thanks in advance for your reply,

  Thilo

  Paul has best suggestion at this point; loops parallel, combined with queues to create an architecture of producer/consumer.

  For an example, see here.

  In the upper loop of the example, you will place a UDP, or even reading your SUB_Collect_Data.vi. The output data would be placed in the queue.

  The lower loop could extract something (your cluster TC Stream) and perform the FFT and UI updates.

  The queue allows the decoupling of processing data acquisition. The top loop withdrew the UDP connection data without stopping to process or display data. The lower loop removed data out of your queue as fast it can run and perform your presentation FFT/AC.

  Note that a queue is up to be exhausted of your system's memory. Using a queue does not relieve you of the treatment of data in some time, but it allows you to take greater advantage of the capabilities of LabVIEW parallel / multiprocessor.

  Search the knowledge base and of producer/consumer forums and you will find many examples...

• Push the connection interrupted by device - using eclipse of the bb Simulator

  Using BlackBerry plugin for Eclipse

  For OS 6

  After taking two weeks to try and correct an error "not close until you have finished" simple with SQLite, I now have a bit of a configuration issue with the Eclipse software.

  When I push a message to the Simulator, I get the following error.

  <2012-04-18 15:39:15.471 EDT>:[378]:::http://172.17.111.35:[email protected]&priority=2&besurl=192.168.1... pushId = -62be8811:136c6f71d73:-7ff576188, destination = [email protected], result code = 400 net.rim.protocol.iplayer.push.b: Push connection aborted by device>
  

  According to the knowledge base, a 400 error is 'invalid Push to the format.

  Mobile data service 3.7 and earlier versions: the email address or the personal identification number (PIN) used in the Push was not recognized as a user of BlackBerry Enterprise Server enabled for Mobile Data Service. »

  I'm sure it's something with the configuration in the rim.property file.  Something probably must be on or off, I can't understand.

  [MonitorAgent]
  MonitorAgent.listen.port=8070
  
  [WebServer]
  WebServer.Tomcat.transcoding= false
  WebServer.listen.host=localhost
  WebServer.listen.port=8080
  WebServer.listen.sslport=8443
  WebServer.servlet.monitor.port=8070
  WebServer.servlet.monitor.host=localhost
  WebServer.servlet.push.port=81
  WebServer.servlet.push.host=localhost
  WebServer.servlet.push.ssl=false
  
  [SRP]
  SRP.UID= please get one
  SRP.AuthenticationString= Please get one
  SRP.InetAddress= Please get one
  SRP.Port=3101
  SRP.logging=true
  
  [IPPP]
  IPPP.push.listen.tcp.port=81
  IPPP.connection.MaxNumberOfKBytesToSend=128
  IPPP.queue.flowcontrol.window.size=-1
  IPPP.queue.flowcontrol.timeout=600000
  IPPP.logging=true
  
  [UDP]
  UDP.receive.port=19781
  UDP.send.default=19780
  UDP.init=initialization_packet
  UDP.logging=true
  
  [HTTP HANDLER]
  application.handler.http.logging = true
  application.handler.http.CookieSupport = true
  application.handler.http.AuthenticationSupport = true
  application.handler.http.AuthenticationTimeout = 3600000
  application.handler.http.device.connection.timeout = 140000
  application.handler.http.server.connection.timeout = 150000
  application.handler.http.device.credentialTimeout = 60000
  application.handler.http.authentication.mechName2oid = Negotiate=1.2.840.113554.1.2.2, NTLM=1.3.6.1.4.1.311.2.2.10, Basic=1.3.6.1.4.1.88888.1.2
  
  [Security]
  net.rim.security.auth.DefaultDomain = rim.net
  
  [HTTPS HANDLER]
  application.handler.https.allowUntrustedServer = false
  application.handler.https.logging = true
  
  [TLS HANDLER]
  application.handler.tls.allowUntrustedServer = false
  application.handler.tls.logging = true
  
  [OCSP HANDLER]
  application.handler.ocsp.StatusProviders = net.rim.protocol.iplayer.connection.handler.device.ocsp.OCSPProvider
  application.handler.StatusProviders.OCSP.PrimaryResponderRank   = Default
  application.handler.StatusProviders.OCSP.Responder.Default      = http://dhobbs-wnt.rim.net/ocsp
  application.handler.StatusProviders.OCSP.UseDeviceResponders    = yes
  application.handler.StatusProviders.OCSP.UseCertResponders      = yes
  application.handler.ocsp.DebugLogging = no
  
  [LDAP HANDLER]
  application.handler.ldap.DEFAULT_SERVER = dhobbs-wnt
  application.handler.ldap.DEFAULT_PORT   = 389
  application.handler.ldap.DEFAULT_QUERY  = ou=people, o=rim.net
  application.handler.ldap.DEFAULT_LIMIT  = 20
  application.handler.ldap.COMPRESSION    = true
  application.handler.ldap.logging        = false
  
  [Database]
  Database.shouldConnect=false
  BESName=DAISY1
  Database.Driver=sun.jdbc.odbc.JdbcOdbcDriver
  Database.URL=jdbc:odbc:BESMgmt
  Database.DBCycleTimer=5
  
  [ACL]
  ACL.Authorization.Datastore=net.rim.shared.service.authorization.JDBCAuthorizationDatastore
  ACL.Enabled=false
  
  [ESS]
  ESS.helpfile    = help/Using_the_Email_Server_Simulator.html
  ESS.launcher    = bin/launcher.exe
  
  [Email]
  Email.deviceId      =2100000A
  Email.pop3Server    =pop3.server
  Email.smtpServer    =smtp.server
  Email.personal      =Dean Logan
  Email.address       [email protected]
  Email.smtpPort      =25
  Email.pop3Port      =110
  

  Any suggestions?

  Figured it out.

  When you set the port of the unit, I had the wrong port

  _notify = (StreamConnectionNotifier) Connector.open (appAttributes.devicePort + appAttributes.deviceSide);

  My company uses a Test port and a port of Prod, so that we can have 2 versions of the application on the device at the same time.  Then, chaning the listening port of 1315 to 1313 authorized service push push to the appropriate port and the app was able to read the data.

• Stand-alone application cannot receive UDP message

  Hi all!

  I have a small work of vi (part of a larger program) to receive udp messages sent by another device on the local network. It works well when it is a normal vi, but

  When I built an exe of this vi, I don't see any udp message received by the exe. Someone has an idea for this? Here's my vi and thanks in advance!

  

  Definitely check the firewall rules. An application is by default not automatically right to create sockets on random ports. Usually, you get a dialog box by the firewall software at first startup of an application, if you want to allow to access network features. But it is easy to close this dialog box without reading carefully and sometimes Windows seems not even to solicit you. And then the firewall rule is normally set to deny network access for the executable.

  For do not push viruses and other malignant software with the nose on the fact that he was blocked, a firewall rule will often calls API succeed but simplyact as if there is no network available.

  And firewall rules are affected depending on the executable name AND location of the executable in the file system. If moving the executable somewhere else will be basically means a new request and requires its own firewall rules.

• Create a broadcast UDP socket and wait to receive a message.

  I am developing a Playbook application using Adobe Air SDK.

  I want to create an application that opens a UDP broadcast socket and wait to receive a message.

  Is it possible to do it with Adobe Air SDK?

  By Adobe documents, it appears profile still not mobile support (I put the filter on the reference of the API for 'AIR earlier 3.1 and runtime').  Note the class property available to test you support when running.

  http://help.Adobe.com/en_US/FlashPlatform/reference/ActionScript/3/Flash/NET/DatagramSocket.html

  "AIR profile support: this feature is supported on all systems of desktop operating, but is not supported on mobile devices or AIR to TV sets." You can test the support at run time by using the DatagramSocket.isSupported property. See AIR profile taken in charge for more information regarding the API across multiple profiles support. »

• UDP send receive application

  Hi all

  I'm writing an application to send UDP packets. I had no problem with the send() call, but I would try to receive the message sent, perhaps on the same connection.  (I use another connection to receive in the same thread, but the result is the same).

  The application thus written, block in the first reception. Could someone help me?

  package ProvaInvioRicezione;
  
  import net.rim.device.api.ui.UiApplication;
  import net.rim.device.api.ui.component.*;
  import net.rim.device.api.ui.container.MainScreen;
  import javax.microedition.io.Connector;
  import javax.microedition.io.DatagramConnection;
  import javax.microedition.io.Datagram;
  import java.lang.String;
  
  public class EsempioInvio extends UiApplication
  {
  public static void main(String[] args)
  {
          EsempioInvio theApp = new EsempioInvio();
  theApp.enterEventDispatcher();
  }
  public EsempioInvio()
  {
  pushScreen(new HelloWorldScreen());
  }
  }
  final class HelloWorldScreen extends MainScreen
  {
  public HelloWorldScreen()
  {
          super();
          LabelField title = new LabelField("Esempio di invio pacchetti",
                          LabelField.ELLIPSIS | LabelField.USE_ALL_WIDTH);
          setTitle(title);
          add(new RichTextField("Cambia stringa cazzo!"));
          //add(new RichTextField("Datagram packet was sent"));
          byte[] outBuff = "Soccia!".getBytes();
          byte[] buf = new byte[256];
      //byte[] buf = new byte[256];
      try {
          //creo socket per mandare il pkt
  
        DatagramConnection connection = (DatagramConnection)Connector.open("datagram://127.0.0.1:2000");
        Datagram outDatagram = connection.newDatagram(outBuff, outBuff.length);
  
        connection.send(outDatagram);
  
        DatagramConnection recConnection = (DatagramConnection)Connector.open("datagram://127.0.0.1:2000");
        Datagram inDatagram = recConnection.newDatagram(buf, buf.length);
  
        while(true){
            System.out.println("Ciao sono qua");
        recConnection.receive(inDatagram);
  
        String received = new String(inDatagram.getData());
        add(new RichTextField("Stringa ricevuta:"+received));
      }
  
      } catch (Exception e) {
          add(new RichTextField(e.getMessage()+":"));
          add(new RichTextField(e.getClass().getName()));
      }
  
  }
  public boolean onClose()
  {
  Dialog.alert("Bye bye n00b!");
  System.exit(0);
  return true;
  }
  }
  

  Problem solved. I used another connection is listening on port even reeive data and udpdemo now work correctly. There was a funny bug tooc the sample application print a message from output og OK don't receive that if the payload of the packet is "RECEIVED"... the payload, not the status

• Impossible to receive packets from UDP broadcast on a PPP connection

  I'm fighting for two days now with no success. I have two modems (don't ask, some special stuff), which uses the dial-up access (PPP). I tried on windows XP and it works like a charm. I'll send unicast and broadcast UPD packets. If I repeat that on Windows 7, I can send only the data of unicast, broadcast packets seems to be lost somewhere, I tried to use the Microsoft network monitor, and I can see that broadcast packets are received on my PPP connection. But after that, they are gone. Somewhere in the kernel. I don't really understand why. I've disabled the firewall, antivirus, motor base, tried to open a session of abandoned filtering packed in the Windows Filtering Platform, clean the WIN7 machine I tried all without success.

  Here is an example of a packet received on the interface, but there most recent scope of my application:

  No.     Time               Source                Destination           Protocol Length Info
        1 13:20:56.093380000 192.168.1.50          192.168.1.255         UDP      49     Source port: x11  Destination port: x11
  
  Frame 1: 49 bytes on wire (392 bits), 49 bytes captured (392 bits)
      Encapsulation type: Ethernet (1)
      Arrival Time: May  7, 2014 13:20:56.093380000 Central Europe Daylight Time
      [Time shift for this packet: 0.000000000 seconds]
      Epoch Time: 1399461656.093380000 seconds
      [Time delta from previous captured frame: 0.000000000 seconds]
      [Time delta from previous displayed frame: 0.000000000 seconds]
      [Time since reference or first frame: 0.000000000 seconds]
      Frame Number: 1
      Frame Length: 49 bytes (392 bits)
      Capture Length: 49 bytes (392 bits)
      [Frame is marked: False]
      [Frame is ignored: False]
      [Protocols in frame: eth:ip:udp:data:vssmonitoring]
      [Coloring Rule Name: UDP]
      [Coloring Rule String: udp]
  Ethernet II, Src: ae:4e:20:00:01:00 (ae:4e:20:00:01:00), Dst: Xerox_00:00:00 (01:00:01:00:00:00)
      Destination: Xerox_00:00:00 (01:00:01:00:00:00)
          Address: Xerox_00:00:00 (01:00:01:00:00:00)
          .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
          .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
      Source: ae:4e:20:00:01:00 (ae:4e:20:00:01:00)
          Address: ae:4e:20:00:01:00 (ae:4e:20:00:01:00)
          .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
          .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
      Type: IP (0x0800)
  Internet Protocol Version 4, Src: 192.168.1.50 (192.168.1.50), Dst: 192.168.1.255 (192.168.1.255)
      Version: 4
      Header length: 20 bytes
      Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
          0000 00.. = Differentiated Services Codepoint: Default (0x00)
          .... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00)
      Total Length: 34
      Identification: 0x0032 (50)
      Flags: 0x00
          0... .... = Reserved bit: Not set
          .0.. .... = Don't fragment: Not set
          ..0. .... = More fragments: Not set
      Fragment offset: 0
      Time to live: 126
      Protocol: UDP (17)
      Header checksum: 0xb817 [correct]
          [Good: True]
          [Bad: False]
      Source: 192.168.1.50 (192.168.1.50)
      Destination: 192.168.1.255 (192.168.1.255)
      [Source GeoIP: Unknown]
      [Destination GeoIP: Unknown]
  User Datagram Protocol, Src Port: x11 (6001), Dst Port: x11 (6001)
      Source port: x11 (6001)
      Destination port: x11 (6001)
      Length: 14
      Checksum: 0xafd1 [validation disabled]
          [Good Checksum: False]
          [Bad Checksum: False]
  Data (6 bytes)
  
  0000  34 34 34 34 34 34                                 444444
      Data: 343434343434
      [Length: 6]
  VSS-Monitoring ethernet trailer, Source Port: 127
      Src Port: 127
  

  I'm out of my ideas, if anyone could help with any idea, please do. I don't know if this possibility is removed on win7 or not.

  Hello

  I suggest you to report your query in the TechNet forums to improve assistance in this regard.

  http://social.technet.Microsoft.com/forums/Windows/en-us/home?category=w7itpro

  Hope this information helps.