Jump to content

Search the Community

Showing results for tags 'network stream'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Software & Hardware Discussions
    • LabVIEW Community Edition
    • LabVIEW General
    • LabVIEW (By Category)
    • Hardware
  • Resources
    • LabVIEW Getting Started
    • GCentral
    • Code Repository (Certified)
    • LAVA Code on LabVIEW Tools Network
    • Code In-Development
    • OpenG
  • Community
    • LAVA Lounge
    • LabVIEW Feedback for NI
    • LabVIEW Ecosystem
  • LAVA Site Related
    • Site Feedback & Support
    • Wiki Help


  • *Uncertified*
  • LabVIEW Tools Network Certified
    • VI Scripting
    • JKI Right-Click Framework Plugins
    • Quick Drop Plugins
    • XNodes
  • General
  • User Interface
    • X-Controls
    • Custom Probes
  • Database & File IO
  • Machine Vision & Imaging
  • Remote Control, Monitoring and the Internet
  • Hardware

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start



Personal Website

Company Website

Twitter Name

LinkedIn Profile

Facebook Page



Found 3 results

  1. I have run into a bit of a problem with how I am trying to do networked messaging between a client and a server application. I am considering trying Network Streams as a solution but wanted to see if anyone has had success (or failure) with this solution or has a better idea. First, a little background on the application: In my system, there are N servers running on the network. Each of these is running on it's own VM with a static IP and unique machine name. There are also N clients. These are running on physical machines, VMs and a Windows RDS (Remote Desktop Server). The messages are all abstract class objects. Both client and server have a copy of the abstract classes so they can send/receive any of the messages. My current solution is to use VI Server to push messages from one application to the other. There is no polling. Clients and servers can go offline at anytime without warning and the application at the other end of the connection must deal with the disconnect gracefully. In normal operation, the client will establish connection to a group of servers (controlled by the user). The client provides it's machine name and VI Server port. Each server then connects back to the client. All messages then pass via these connections. Therefore, a client is uniquely identified to the server by its network machine name. Now the problem. A Windows RDS session does not have a unique machine name. Instead it uses the machine name of the RDS. So, if two users run the client application in two separate RDS sessions at the same time, when they connect to the servers, they will look like the same machine. There is no way to uniquely identify them and route messages to the correct one. So, I have started looking at network streams as a possible solution. They looked interesting because you could add a unique identifier to the URL so you could have more than one endpoint on a single machine. This looked like it would solve my problem because I could combine the machine name and user name to make my client endpoint unique. But here is the process I would need to follow: Server creates an endpoint to listen for client connections. Client gets the list of server names (from a central DB) and then tries to connect to each server's endpoint. If successful, the client creates a unique reader endpoint for that server and then passes the server the information about how to connect to this endpoint. When the server connects to this endpoint, it also creates a unique reader for the client and sends that info. The client connects to the server using this unique endpoint and we now have two unique network streams setup between client and server, one in each direction. The client then disconnects from the first server endpoint since it now has its own unique connection. Both ends will need to have some sort of loop that waits for messages (flattened class objects) and then puts them into the proper local queue for execution within their application. Both will also need to be able to send a shutdown message to each of these loops when exiting to close the connection. My concerns are how to have the server listen for connections with its generic endpoint to multiple clients at once. There is no guarantee that only one client will try to connect at a time. And once the client is fully connected and releases the generic connection, will the server be able to listen for more connections or will that endpoint be broken? How do I reinitialize it? This is all so much easier with VI Server that I might have to just give up on the RDS solution altogether. But I want to give this my best shot before I do that. Thanks for any tips or ideas or pointing out any pitfalls I missed. -John
  2. I'm trying to find a way to communicate between two executable LabView app, because of several reasons I chose (associated with my application) Network Streams. Everything works fine so long as they are the VIs. When I build exe files there is no communication between apps. The apps waits forever for connection (because there is no timeout). Did anybody meet the same problem? I will be very grateful for any advices and comments. TestStream.vi TestStream2.vi
  3. What is the best practice for creating n number of network steams? Thanks, Brad
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.