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.
Related
I'm wondering if for simply communicating with a PLC, like reading and writing tags, do I need all of the other heavy lifting that comes with an OPC-UA server?
I've tried writing a simple server in Python that talks to the PLC, but I get denied when requesting information from the PLC.
The Controllogix PLC I'm attempting to communicate with uses Ethernet/IP to communicate, so why doesn't a simple server/client script work? What is required exactly to communicate with an Allen Bradley PLC or PLC's in general?
There is quite a bit required to communicate with a PLC.
Each vendor has a driver, there are firmware compatibility considerations. Different protocols to think about.
OPC-UA makes it a bit more generic, but OPC-UA still has a set of things to work around when setting up communications.
Most of the OPC products I've worked with, needs to have their security adjusted to allow anonymous communication. It's generally bad practice to do this. (A network intrusion would be able to read/write to your automation layer) There is certificate signing and some encryption business that needs to be turned off if you're looking for simple communication. (Again, not a good practice but ok for learning)
After all that you have to have a notion of how your PLC is set up on your OPC server, there are channels, devices, namespaces etc. You'll point the OPC client to some opc.tcp://:
If you got this far you're almost done, I'm assuming your OPC server is running and has tags configured at this point. You can use your OPC-UA API to do a read. It can return just the value, or you can get an object back with tag health, timestamp, and a bunch of other data. Depends on the implementation. After that you can do subscriptions, writes...whatever else you need.
TLDR: OPC server not required, but may be the easiest method. Turn off security. (But turn it back on before exposing your control layer to the net)
I am also a little late to this conversation. If you are interested in coding your own solutions and don't want to use any of the commercially available standards, AdvancedHMI is a "mostly" open source solution written in VB.NET which is 100% free and provides communications to many different PLCs including the ControlLogix platform. Since I see you are programming in Python you may also be interested to know that the project does work under Mono on the Linux OS. I have used it to write gateways between EthernetIP and ModbusTCP and to pull data serially from OEM devices and push this data to a CLX PLC.
The forum is full of many helpful hints and is very active and supported.
Just trying to give you another option. DDE, NetDDE, FastDDE, OPC, DCOM, Suitelink.... These are all good, but mostly a pay to play adventure. As a programmer, it seems ridiculous to have to pay such an excessive amount of money just to talk to my hardware, IMHO. Sorry for the rant. Have Fun!
Update - Just wanted to also suggest the following open source project written in python:
https://github.com/dmroeder/pylogix
I have used this to write small programs for communicating with CompactLogix and ControlLogix. (Even to/from a RaspberryPi!)
Depends on several factors, if you want something simple to program you can opt for Modbus/TCP I think some AB PLC supports it without extra hardware.
However if you want something with more security for example for industrial use then OPC UA would be better choice but the programming has a complexity far higher than Modbus, even using the libraries of OPC Foundation or others. There is the option of using a commercial or free (if any) OPC UA server to save work, then you will need to program the client side only.
With Ethernet/IP it should also be possible, but the problem is that there is no clear specification and even different AB models talk different Ethernet/IP dialect ! , it is also far more complex to program than Modbus.
I am a little late to this discussion, but there are a couple commercial tools that make this a bit easier. The one that comes to mind for me when you say you are using python is Cogent's data hub. It is certainly not the cheapest tool out there, but they have already done all of the heavy lifting for PLC/PC communications & security.
If trying to read CLX data using Python, there are several open source implementations that will save you a lot of work. Such as this:
https://github.com/dmroeder/pylogix
If you use .NET and Visual Studio, you can use AdvancedHMI
to be able to read and write OPC Tags to ControlLogix platform is done via its communication Driver RSLinx. RSLinx acts as an OPC Server, it will need to be configured to communicate with the PLC and run on a networked PC on the same LAN. Several flavours of RSLinx are available (for WAN/VLAN also) but essentially this is the communications driver you need to talk to AB PLC's
I will be developing a protocol that will encompass a client and a server module.
Several protocols that are close to the one I have in mind exist, but I want to make something simpler with less overhead and with something I have more control on.
The protocol I will be doing can and will be run almost in any scenario, local, web, lan, internet, etc. It can also run on a single box.
My question is, how can I start developing for the server side of the protocol?
Any ideas, insights, key words, starting points would be appreciated.
Regards
Do you want to develop the protocol yourself and then use it? or you are looking for a good protocol to use?
If second, I have recently worked with "Websocket" protocol which enables clients to communicate with each other via a server. It is a really good protocol and there are libraries in .NET ( >= 4.5), JAVA, Javascript, ... It is also supported in many browsers.
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.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
I think I summed it up in the title. Regarding the question, I have been evaluating my options for utilities that allow me to craft, capture, and analyze TCP/IP packets. I am very new to network programming and I am still learning as I go, but at this point, I want to write a program that establishes a TCP connection.
Here are my goals (long term to short term):
Deploy and code a system that can establish an ssh connection between two computers behind NATS given their local host names (i.e. feynman.home to feynman.work) and the IP addresses of their routers. I would also like to be able to guide the connection across a set of hops if possible/necessary.
No using third parties or closed source code of any kind. #
Rewrite (and possibly modify) pwnat in a "cleaner" format (i.e. using some well developed library for a high level language.)
Establish ssh connection between two hosts behind the same NAT (using my own code of course.)
Establish TCP connection between two hosts behind the same NAT (using my own code of course.)
I have managed to find netexpect which seemed very promising until it failed to build on my Mac OS X (my computer is going through a glitchy period right now.) Netexpect may well be the best option, but I have come across quite a few others (e.g. scapy and its perl and ruby implementations.) Many of these are not well maintained (e.g. scapy and its perl and ruby implementations.)
So, I thought it would be best to bring the question to stackoverflow (unless there is a better stackexchange I am not aware of.)
*Given the current state of my computer (don't ask) portability is important.
*I would prefer something well maintained/under active developement as to best assure I will have all the tools I will need for my short and long term goals.
*Finally, I would prefer something that uses an interpreted language for a host of reasons ranging from my experience to my preference.
#Yes I am fully aware there are easier ways. I want to do it my way because this just as much a learning experience as it is practical.
I know you are looking for a library on an interpreted language, but libcrafter is very easy to use. Is a C++ library for crafting and parsing network packets. On the future, it will support more protocols.
Most of what you described involving routing the connection between multiple hops/NATs - isn't done in the SSH client at all. It would involve having access to several network routers and setting up all those NATs in advance, then those translations would already happen automatically when the connection is routed through.
Are you talking about proxying your connections through multiple servers? That could be accomplished by a macro that logs in to server A, then automatically invokes ssh again from server A to get to server B and so on.
Could you describe in some more detail what you are trying to accomplish?
Edit: I just read the description of pwnat. That is incredibly proprietary (and won't work in every situation anyway, since many configurations block ICMP completely). If you really wanted to try it out, you'll probably be stuck with C/C++. I don't think Java or .NET gives you the kind of low-level flexibility that you would need to packet craft, for security reasons. Have you looked at Ostinato: http://code.google.com/p/ostinato/wiki/Downloads?tm=2 or Nemesis: http://nemesis.sourceforge.net/
Pretty much everything on windows will use winpcap and on *nix it will use libpcap.
While I haven't tried it, this might work: http://www.codeproject.com/Articles/12458/SharpPcap-A-Packet-Capture-Framework-for-NET
It says it SharpPcap handles interfacing with winpcap... so depending on what they implemented, or whether you can extend that functionality, you may be able to put something together.
Or, in java, you might be able to use something like this as a starting point: http://jpcap.sourceforge.net/
libtins is an open source, multi-platform, C++ library I've been developing for the past year. You can forge, sniff and interpret packets from network interfaces using it. It's very simple to use, and it provides a high level interface so you don't have to worry about endianness, internal protocol implementations, etc.
You can have a look at it at the library's website.
I would like to ask a question about network communication.
The Question is:
A server uses the socket interface on the Lunix platform,
and a client uses Winock on the Windows platform.
Can they communicate?
Explain briefly.
I guess the answer is NO.
I guess it is due to the compatibility between 2 different socket interface?!
But I am not sure my estimation is right or not.
So, I hope someone could give me some comments about this questions.
Thank you very much!
Not right at all.
The APIs are different, but both sockets create packets written to a standard format described in RFC 793 and lots of subsequent revisions and additions.
Follow that packet format, and implementations written for different platforms and in different languages will talk to each other.
This is the magic of the internet.