I want to write a script on windows using WSH jscript to be compiled by jsc.
I want the script to act as a very simple tcp server, listening to any port specified, and sending a text string upon receiving any request.
I have found some implementations which depend on a library that seems to only be available on windows machines with developer software installed. I need an implementation that can work on any windows machine (with .NET installed). I am happy to include a dll if there is one that can help to listen on tcp sockets.
Is there a suitable dll to act as a tcp server?
Is there a tcp server implementation in jscript that can be compiled with jsc?
It sounds like you're talking about JScript.NET, which is separate from WSH. Since JScript.NET is a CLR language, you can use any of the available .NET Framework classes. Your best bet may be to find an example of a TCP server written in C# or VB.Net and then convert the code to JScript.NET.
Related
I learned the hard way that modern Windows machines do not permit sending TCP data over raw sockets after trying to perform the TCP handshake myself in Python. And yet Scapy, a Python library, is able to do it seemingly just fine. Other libraries, like Npcap and WinPcap, also seem to be able to send raw TCP data just fine on Windows. How is this possible? What are these libraries doing under the hood that enables them to bypass this limitation?
WinPcap (the windows implementation of libpcap) authors say in their website:
WinPcap consists of a driver that extends the operating system to provide low-level network access and a library that is used to easily access low-level network layers.
So the answer to your question would be: in windows, the implementation of libpcap (which is what Scapy uses according to their site) uses a driver to get access to the low-level networking stuff
I have a C# .NET Core 2.1 application that runs fine on windows. A listener task for incoming UDP packets and another thread which sends UDP-packets. The software communicates with an embedded device using a proprietary protocol above UDP which requires "PING-PONG" (ACK) in order to "stay alive".
When running the application on windows I have no problem with the communication. When I run this on Linux Ubuntu (18.04) I sometimes have trouble communicating. Sometimes the communication is lost (packets don't arrive to the application although they are visible in Wireshark) and so on, basically it behaves bad...
The code more or less uses basic stuff from online tutorials for the "back-bone" of UDP communication (listener and so on). Do you have any idea what's going on here?
It turns out it was a combination of linux socket buffers which I increased to:
net.core.rmem_max=26214400
net.core.rmem_default=26214400
net.core.wmem_max=26214400
net.core.wmem_default=26214400
(in /etc/sysctl.conf)
and proprietary protocol specific bugs...
Currently I'm developing a data acquisition program for my experiment in C++ from a Linux based machine (Ubuntu), I also have many VIs in Labview who is programmed in Windows to control the instruments of the experiment (motors, Signal Generator..). The purpose is to have a 2-way communication between 2 pc, the Linux will ask which VIs to be executed, and when it's finished, send back a signal to Linux machine.
My questions are:
Can I send a signal or a command to Labview in Windows from Linux (Terminal, and it can be implemented into my C code) and vice versa? How?
TCP Labview could be a solution? Or should I try to set the inter-PC "talking" through serial communication (which is easy to setup physically)?
The best (also the easiest) way is to implement TCP-based client-server communication (TCP will ensure data is lossless. When using other mechanisms like UDP or serial you should always make sure your commands are received correctly).
At LabVIEW site, you will have TCP listener (server) which will listen to commands from the Linux machine at your specified port.
Upon command reception, LabVIEW code can do the work and reply by the same TCP connection.
This is very good article about your question: https://decibel.ni.com/content/docs/DOC-9131
Their are several choices for communicating between C++ and LabVIEW. (As well as Linux / Windows).
If you are willing to run LabVIEW on your linux machine you can make use of several of the LabVIEW communication architectures. Here is NI's white paper.
http://www.ni.com/white-paper/12079/en/
Provides choices such as Shared Variable, Network Streams, Web Services, TCP/IP.
You can also take your LabVIEW code and compile it to a DLL and call it from C++ to make use of some of the above features. If not you are likely going to have to go to the TCP/IP route or web service.
I would recommend using TCP/IP, its pretty simple to implement on both sides.
If you are more familiar with serial protocols you can also use them to communicate.
Is there some (working) example how to create RPC from windows to linux?
Client should be windows NT application, server is linux.
It needs to be MSRPC.
No Corba, no XML-RPC, SUN-RPC etc
MSDN says this:
RPC can be used in all client/server applications based on Windows
operating systems. It can also be used to create client and server
programs for heterogeneous network environments that include such
operating systems as Unix and Apple.
Unfortunately after spending few hours on google I'm giving up.
My expectation:
Linux node should have samba installed, because their MSRPC implementation works.
Using IDL file I generate stubs for both client and server
Client is built using MSVC
Server is build using gcc with some includes/libraries from samba (or other libs)
Linux node must have such RPC port mapper
Can someone point me out?
I think you have 2 possible ways to deal with this:
1- You can try using DCOM with wine, which means that you will actually write your code for windows, but at the same time you can test your results in the process and avoid using WinAPI calls that wine is not able to handle properly. This approach will allow you to generate stubs code from your IDL files.
2- You can try using Samba RPC Pluggable Modules, but I am afraid in this case the RPC communication will be more primitive.
Edit:
It seems there are many other ways. I found a list of libraries in DCOM-Wikipedia, j-Interop for example looks particularly promising.
i am newbie to Linux platform, i am working on java technology.
what i have to do is : Having a program that running on mobile devices,that sends some data to my Linux machine, now i have to create a program in java that
listen to a particular port.
access data comes on that port(which is sending by mobile device)
save that data to the database.
response back to the mobile device.
i.e. i would make my Linux system as server that can listen from many clients(mobile devices), but not getting how to configure this environment... :(
i used cent OS 5.4 and
installed jdk1.6.0_24
any help would be appreciated.....
thanx in advance!
khushi
One of Java's greatest strengths is that you can pretty much ignore the host operating system as long as you stick to core Java features. In the case you're describing, you should be able to accomplish everything by simply using the standard Java networking APIs and either the JDBC to access an existing, external database or you could choose any number of embedded Java databases such as Derby. For your stated use case, that you'll be running the application on Linux is pretty much irrelevant (which should be good news... you don't need to learn a whole operating system in addition to writing your app ;-).
Here's a nice client/server tutorial, in that it is broken into steps, and adds each new concept in another step.
Here's another client/server tutorial with much more detail.
I would write it to accept one connection at a time. Once that works, I would study the new(ish) java.lang.concurrent classes, in particular the ExecutorService, as a way of managing the worker bee handling each connection. Then change your program to handle multiple connections using those classes. Breaking it up in two steps like that will be a lot easier.