I have least knowledge on network domain.Please bare with my question if it is basic
I would like to know how to communicate between two applications using TCP/ip protocol in
windows XP say for example
Using Perl and TK I am building a GUI with entry widget and i have an other external application which is installed in the system say APPLICATION.exe
Now i need to establish the connection using TCP between my perl program and external application APPLICATION.exe
for testing purpose what ever I type in the GUI Entry this external application has to receive (hope it receives as bytes)and external application will send some data and i need to process that data in my perl program..
I am totally unaware whether this is simple task or complicated.
If there are any modules existing in perl for similar programming please suggest me.
I highly appreciate if anyone can provide me the answer with an example.
Thanks to all
It is simple if you have done network programming before. If not, it is intermediately difficult because you need to get a grip on the underlying concepts and terminology first - read a book about the topic if necessary.
I recommend to use IO::Socket::IP. If you have Perl 5.14 or later, you can also use IO::Socket::INET that is distributed with Perl. See https://stackoverflow.com/a/8582550/46395 for a code example and links to further documentation.
Related
im a university student and I've been tasked with creating a simple File Transfer Protocol using TCP between two machines.
I have very basic knowledge about sockets, and I've been using Linux for a bit. Is it possible to create two virtual machines on VirtualBox (linux machines) and have one be the server and the other be the client? Is that the right way to go about it?
Another question I have is for protocol specification. Is this something I specify in the client or server program or in a separate program?
Other than that, I would appreciate any useful resources or examples you can provide me as a starting point, as it's taking me a lot longer than I thought to really understand how to accomplish this through resources I currrently have. I apologize to any of you who feel this is an unproductive post but I am simply seeking any advice I can get from you more experienced programmers out there.
Thanks!
Is it possible to create two virtual machines on VirtualBox (linux
machines) and have one be the server and the other be the client? Is
that the right way to go about it?
You can do that, but to start with you might find it simpler to run the client and server programs both on the same host. There is no requirement that they must run on separate machines (virtual or otherwise).
Another question I have is for protocol specification. Is this
something I specify in the client or server program or in a separate
program?
The protocol specification is part of the documentation; it's not part of either program. Both programs will have to follow the specification in order to interoperate with each other properly, of course.
Other than that, I would appreciate any useful resources or examples you can provide me as a starting point,
Pointers to resources/examples are off-topic for StackOverflow, but you can google e.g. "TCP programming tutorial" or "TCP programming FAQ" or similar and you should find lots of content.
We have a Beckhoff EtherCAT Coupler which is currently being controlled by some c# code, we call that c# code from a powershell script. We want to move the entire process of toggling slots on the coupler to the powershell script but I'm not sure how to do that. If you could provide me even with information on how to send/receive Modbus commands in powershell that would be hugely helpful.
Thank you!
EDIT:
Here is the code used in C# to toggle one slot of the IO coupler:
using System.Net.Sockets;
using Modbus.Device;
TcpClient tcp_connection = new TcpClient(ip, MODBUS_TCP_PORT);
ModbusIpMaster coupler = ModbusIpMaster.CreateIp(tcp_connection);
coupler.WriteSingleRegister(0x1120, 0);
coupler.WriteSingleCoil(slot, state);
Acontis offers an EtherCAT Master for Windows library and a C# example application you could leverage to include into your own application: https://acontis.com/en/ecsta.html
Working with machine automation controllers is highly manufacturer specific. I've got working knowledge only about Omron PLC & MACs, so I cannot provide exact details.
Anyway, one way would be to create a C# DLL and call it from Powershell. As how to program the coupler, start by finding out which model, exactly, you are working with and searching Beckhoff's documentation. Maybe there are suitable samples available.
Consider also contacting manufacturer's support. They might be able to provide advice with very reasonable pricing, unless the task grows into a consulting gig.
Programming PLCs and MACs is often done via manufacturer specific solutions. Those are much simpler to use than general-purpose language such as C#.
How could one interact with a locally long-running Common Lisp image, possibly daemonized, from the command line?
I know it is possible to run a Common Lisp function from a Terminal command prompt, I am also aware of this.
I would need to do a similar thing, but with a local, already long-running Common Lisp image, being able to poll available functions from the CLI or shell scripts.
Is there a way to do that from a CLI, for example calling a function from a bash script, and receiving back whatever the function returns?
I though one could, for example, create a primitive web service, perhaps using woo or Hunchentoot, calling functions and fetching returned values via curl or wget, but it feels a little convoluted.
Of course, that is one of the many features of Emacs' SLIME, but I would need to call functions just from the CLI, without invoking Emacs.
Is there perhaps a way to reach a swank backend, outside of SLIME?
If possible at all, what would be the lisp idiomatic way of doing that?
I would be grateful for any pointers.
Update
Additional note
Many years ago, I was intrigued by being able to telnet into a long-running LISP image (I believe in this case uppercasing the name should be fine). If I remember correctly, it was available at prompt.franz.com. An article, somehow connected: telnet for remote access to a running application
Telnet is of course quite unsafe, but the usefulness of being able to access the Lisp application(s) in that way, for whatever reason, cannot be overstated, at least to some people.
Some additional pointers, and thanks
I would like to thank Basile Starynkevitch for his elaborate and thorough answer, especially on the theoretical aspect. I was looking for a more practical direction, specially connected to Common Lisp. Still, his answer is very instructive.
I was all ready to start writing a local server, perhaps using one of the fine Common Lisp libraries, like:
usocket: Universal socket library for Common Lisp
iolib: Common Lisp I/O library
cl-aync: Asynchronous IO library for Common Lisp
But, thanks to Stanislav Kondratyev, I didn't have to. He pointed out an already existing solution that nicely answer my question, ScriptL: Shell scripting made Lisp-like
I tested it with success on Linux, FreeBSD and OS X, just make sure to install the thin wrapper over POSIX syscalls first. Among many features (see README), it allows exposition of just selected functions, security is properly handled, and it even supply a custom C client, which builds as part of the ASDF load operation, and supports a number of new features, such as I/O, in place of netcat.
You may find scriptl useful: http://quickdocs.org/scriptl/. However, it depends on iolib, which depends on some nonstandard C or C++ library, so building it is not quite straighforward.
It is indeed possible to communicate with a swank server if you familiarize yourself with the swank protocol, which seems to be underdocumented (see e. g. here: https://github.com/astine/swank-client/blob/master/swank-description.markdown). However, this exposes a TCP socket over a network, which could be unsafe. Once I tried that, too, but I was not satisfied with the IPC speed.
A while ago I wrote a rather naive SBCL-specific server that uses a local domain socket for communication, and a client in C. It's very raw, but you could take a look: https://github.com/quasus/lispserver. In particular, it supports interactive IO and exit codes. The server and the client form the core of a simple framework for deploying Unix style software. Feel free to borrow code and/or contact me for explanations, suggestions, etc.
It certainly is operating system specific, because you want some inter-process communication, and they are provided by the OS.
Let's assume you have a POSIX like OS, e.g. Linux.
Then you could set up a socket(7) or fifo(7) to which you send s-exprs to be evaluated. Of course you need to adapt the Common Lisp program to add such a REPL.
SBCL has some networking facilities, you could build on them.
Of course, you should understand first how IPC work on your OS. If it is Linux, you could read Advanced Linux Programming (it is centered on C programming, which is the low-level way of using OS services on POSIX, but you can adapt what you have learned to SBCL). And indeed, the Common Lisp standard might not have an official POSIX interface, so you need to dive into implementation specific details.
Perhaps you should learn more about BSD sockets. There are tons of tutorials on them. Then you could use TCP sockets (see tcp(7)) or Unix ones (see unix(7)). Advanced users could use the unsafe telnet command. Or you might make your software use SSL, or perhaps some libssh e.g. use ssh as their client.
You could decide and document that the protocol between user apps and your program is : send some-sexpr (on a documented socket) from user-app code to your server which is terminated by a double newline or by a form feed, and have your server eval it and send back the result or some error message. I did similar things in MELT and it is not a big deal. Be careful about buffering.
I guess that you assume that you have responsible and competent users (so don't open such a remote REPL to the wild Internet!). If you care about malicious or stupid use of a remote REPL, it is becoming complex.
Alternatively, make your server a web application (by using some HTTP server library inside it), and ask users to use their browser or some HTTP client program (curl) or library (libcurl) to interact with it.
I have received a job at a hospital which still uses COBOL for all organizational work, the whole (now 20 Terabyte) database (Which was a homebrew in, guess what, COBOL) is filled with the data of every patient since the last 45 (or so) years.
So that was my story. Now to my question:
Currently, all sockets were (from what I've seen) implemented by COBOL programs writing their data into files. These files then were read out by C++ programs (That was an additional module added in the late 1980s) and using C++ sockets sent to the database.
Now this solution has stopped working as they are moving the database from COBOL to COBOL, yes - they didn't use MySQL or so - they implemented a new database - again in COBOL. I asked the guy that worked there before me (hes around 70 now) why the hell someone would do that and he told me that he is so good at COBOL that he doesn't want to write it in any other language.
So far so good now my question:
How can I implement socket connections in COBOL? I need to create an interface to the external COBOL database located at, for example, 192.168.1.23:283.
You need to give more information about your OS and compiler.
If you are on IBM z/OS with a Language Environment supported compiler, you can just call the EZASOCK functions from the z/OS communications services. The calls are well documented in their references and have good Cobol examples.
Other platforms will have other options.
In most cases, you can just "CALL" an external module written in whatever language you need, but that a DLL or a sharedLib or whatever.
Can you give some more detail about your environment?
Why don't you just write directly to the database from the Cobol program?
IBM mainframes has two sockets APIs that can be used form COBOL.
One for use inside a CICS programs (where there are special thread safety and envrinment considerations) and one for use in ordinary Batch or IMS programs.
The complete TCP/IP functionality is implemented and its reliable enough to handle Credit Card protocols to MVA standards ( I know 'cos Ive done it).
Most COBOL compiler will allow you to link and call in an object module or DLL. As Kati says I know I can help but need the additional information. I've done this previously from windows to DEC so i know it can be done.
Recall that Google is your FRIEND.
The answer will depend heavily on your execution environment.
IBM does claim to have a Sockets API callable from COBOL, as part of CICS for z/OS.
Micro Focus appears to have something.
I need to move some data from one machine to another. Is it a good idea to write a client server app using sockets in Perl to do the transfer? Will I have problems if one side is written in Java?
I mean, should I be aware of any issues I might face when I try to attempt the above?
Short answer: Using a Perl program as the client or server is just fine. Your only problem might be your personal skill and experience level, but after you do it you know how to do it. :) Most of the problem is choosing how you need to do it, not the technology involved. Perl isn't going to be the problem, but it doesn't have an advantage over other languages either.
As some have already noted, the socket portion of the problem is going to be the same in most languages since almost everything uses the BSD stuff. Perl doesn't have any roadblocks or special gotchas for that. To move data around you create one side to listen on a socket and the other to open a connection and send the data. Easy peasy. You might want to check out Lincoln Stein's Network Programming with Perl for that bit. That can get you the low-level bits.
For higher-level networking, POE is very useful and easy to work with once you get started. It's a framework for dealing with event-driven programming and has many plugins to easily communicate between processes. You might spend a little time learning it, but it gives a lot back too.
If you aren't inventing your own protocol, there's most likely already a Perl module that can format and parse the messages.
If you just want to transfer data, there are several things you can do. The easiest in concept might be just to write lines to the socket and read them as lines from the other end. A bit more complicated than that is using something like Data::Dumper, YAML, or JSON to serialize data to text and send that. For more complex things, such as sharing Perl objects, you might want to use Storable. You freeze your objects, send them as data over the network, then thaw them on the other side.
If you want to implement your client and server in different languages you have a bit more work to figure out how they'll talk to each other. The socket stuff is mostly the same, but a Java server won't understand the output of Perl's Storable (it's possible, but you'll have to parse it yourself and that's no good :). If you do everything right, neither side should care what you used on the other side.
I can only think of one gotcha off the top of my head: most text based network protocols use CRLF for line endings, but Perl on UNIX type machines assumes LF endings by default, this means you will need to change the input and output record separators if you want to use readline (aka <>) and print (also beware of printf, since it doesn't use the output record separator). Of course, if you are going to use a pre-existing protocol, there is probably already a Net::<PROTOCOL NAME> module on CPAN, so you won't need to worry about that. If you are designing your own protocol, I would keep the CRLF convention because it makes it easy to debug the server with telnet (which is really the last valid use for that program).
You don't say whether you need to implement your application to support any particular protocol or whether you need to implement a home grown protocol. The networking support in Perl is flexible enough to support either (or most places in between).
At the low level socket end, your code is going to be fairly similar whatever language your are using - BSD socket APIs are pretty well the same everywhere they are supported. The support you need for this is built into Perl but low level socket programming can be frustrating - it's very low level.
However, Perl's standard library contains the Socket module which is rather easier to use (and well documented).
If you need to implement an existing protocol you may well find that it has already been implemented. For example Net::Telnet implements command/response protocols (like Telnet) making a client app trivial.
Searching CPAN may save you a lot of pain. Look at modules in the Net::* hierarchy
I don't think you're gonna have any major issues that you won't have by not using Perl. Even performance will be comparable to other solutions due to network latencies.
You might want to look at POE framework. It makes writing such components a breeze.
It probably depend on a few factors. Does speed or responsiveness matter? Are you moving data between they same type of machines (Unix to Unix, Windows to Windows)? What type of data are you trying to move (Text or Binary)? What is knowledge about sockets and what languages do you have experience?
I have sent and received binary data over PERL sockets from differing applications, but I don't have much experience with the text processing over sockets from differing machines. If you are moving data between machine you need to keep in mind the way the data is marshalled and if it is packed or aligned on some byte boundry. I have not exchanged data with a Java programs, but is should be similiar.
It probably would help to have some experience with PERL, and I would recommend looking at the examples in the "camel" book. I have used the ones in the book as a starting point and made modification for what I needed to achieve. You may have to consult some other areas of the book if you are dealing with binary data, or to help in doing translations for sending data.
Write socket communication in Perl is relatively easy. Do it right and reliable is big pain even CPAN modules are examples of error prone code. It depends of your expectations.
You are basically asking two questions:
Is Perl a proper language for socket communication?
Is Perl a proper language for UI?
Referring to e5's answer, Perl is indeed a string-centric language with a focus on readable strings, less well equipped to handle binary data. Thus the answer probably lies in the questions: Is your communication string based? Is your UI string based?
If doing binary interaction through a socket, well, you probably could be doing better than Perl (not talking about C, but maybe C-ish languages). If you want to do graphical user-interaction you probably reach faster results by choosing one of the higher languages that focus more on gui interaction. (Java-ish might be the thing here.)