I would like to build a communication protocol between COBOL and C# applications. I didn't find the right way to connect these two applications. The only possible way is to write data by COBOL to a file and read it by C# application and vice versa.
Can I use socket techniques to create such communication, because the file method has bad performance? Or are there any other methods of communicating data between these two languages?
Can I use socket techniques to create such communication [...]?
Of course! You just need to make one a socket server and the other the client + creating + implementing a protocol (if it is just one client + server and you don't need secure communication this is quite easy). You may already have a socket option in your COBOL environment or use external libraries like the free CBL_GC_SOCKET (works for many COBOL implementations, as long as they can call C/C++ binaries).
Or are there any other methods of communicating data between these two
languages?
A multitude (especially if they run on the same machine).
Depending on the COBOL environment used you may have a direct .NET-assembly option and CALL/invoke, or can write a layer to do so with running COBOL code translated to native code within C#.
Direct input/output is often a solution (depends on the needs and the environments, not all have a bi-directional pipe option).
talk to a message queue server (likely not superior in performance)
if the COBOL environment supports it: create a REST endpoint and use this for communication; or do it the other way around talking from COBOL to a REST service implemented in C# (REST from COBOL is likely the "most portable" way of those mentioned, but also the one with the worst performance)
...
Conclusion: there is nothing that hinders COBOL to "communicate" with any reasonable "other programming language", you mainly have to see what you're COBOL and "other programming language" provides and what your goals are.
Related
I have a .NET \ C# class that loads a structure into memory. There's a C++ application on the same machine that need to be able to query the in memory structure.
My question is around performance. I could expose the functionality as a COM object that the C++ could call via COM ... or I could implement it as a WCF service that I believe the C++ application would be able to query via Named Pipes ...
Does anyone have any experience with performance either way? I've fond some great stats comparing WCF Named Pipes Vs. TCP vs. HTTP, but I don't know enough about COM to make an educated decision on how it'll perform. Any thoughts would be appreciated.
Thanks
Warrick
MS SQL works via named pipes (based on tcp channel, generally speaking), so I think it's perfomance is good enough.
Take a look at Choosing Communication Options in .NET
AFAIK today WCF's named pipes/tcp conversation is recommended way to do interprocessing via network (LAN or global). WCF is the successor of Remoting and supplants COM/DCOM for managed code. But remoting is not deprecated/legacy yet and can be used for cross-appdomain binary communication.
I want to study network programming, there’s a chapter named “networking” in “C# in a nutshell”, this chapter contains ‘WebClient’, ‘HttpClient’, ‘FTP’, ‘TCP’ and so on. But some body tell me to study WCF, I want to know what’s the relationship between WCF and c# networking programming, I remembered I have seen somewhere that WCF encapsulates network programming, it’s more flexible and convenient, but not efficiency. Does this mean the relationship between them like ado.net technology with orm? Which I should to study, network programming or WCF? Does c# network programming an obsolete technology?
Thanks
"network programming" usually refers to sockets, this is the lowest level of network communication and deals with pushing bytes on the network - all the other communication systems are built on top of sockets.
Most projects don't use sockets directly because there are simple higher level systems you can use but I think it's still worthwhile to learn the basics because it's not so complicated and it will help you deal with problems in those higher level systems.
The next level is WebClient and friends, those are relatively straightforward classes that implement a communication protocol on top of sockets (for example HTTP).
It's definitely worth your time to learn how to use those because they are simple and extremely useful (for example if you want to pull a file from the internet or communicate with a 3rd party service).
At the highest level you have WCF, this is an extensive (and in my personal opinion over-complicated and over-engineered) framework that gives you a class interface for an external network based service while trying (unsuccessfully) to hide all the communication details.
WCF is very popular in big organizations and "enterprise systems", so, if you want to get a job developing enterprise systems for big organizations learning WCF is a very smart career move.
So, my advice, start with sockets, learn just the basics - this will help you understand how things work under the covers (this will become very useful when you have to debug network problems).
Than move on to the higher level classes, write a simple program that uses WebClient to read a page from the internet so you are comfortable with the concept, don't bother
with all the advanced options, they are there and you can look them up later when you need them.
Learning just the basics of sockets and WebClient should take just a few hours, after that (if you want to work on big systems) learn how to use WCF.
Then you will have the WCF knowledge for your resume and you will know how to just get something over the internet with a few lines of code without using a gigantic framework when you don't need it.
If you want to study network programming you'll want to read about sockets and TCP/IP (and later on UDP if you want to stream or smaller packets). Sockets are the API that most OS:es uses to handle protocols like TCP/IP.
Your comparison is correct. WCF is a framework on top of the networking layer in .NET. Just as ORMs are frameworks on top of ADO.NET.
WCF is not the so called network programming. They are two concepts with some relationship.
Usually network programming means socket programming and TCP/IP. You are supposed to be familiar with protocols, such as HTTP, FTP, SNMP and so on. Then you can write programs that serve as protocol servers and clients. Network programming is still hot, though it is no longer that popular.
WCF is a framework for web services, which is HTTP only (mainly SOAP).
If possible, you should learn both or at least know of both.
I have a C# server application and it needs to talk to and control another 3 client applications: one in C#, one in C++ and one in VB.Net. All of them are Windows Form applications. They basically need to exchange some strings and numbers, not heavily loaded. What is the best way to do IPC between C# and those different languages? Note that clients don't talk to each other, they only talk to the server.
C# needs to talk to C++ so I guess WCF isn't good, as WCF only works between two .Net applications?
Can I use named pipes conveniently in all these languages: C#, C++ and VB.Net?
I also want to know if in the future I have to add VB6, VBScript and PowerShell scripts as clients, what would be the best IPC option that works for all these 6 languages? Will I still be able to use named pipes?
Actually WCF configured to expose services via HTTP might be the best option for the list of languages you want to support.
If you don't like WCF consider exposing HTTP REST interfaces i.e. by writing server in ASP.Net MVC.
Named pipes support - C#/VB.Net, C++ - good, VB6 - I don't know, VBScript - definitely not out of the box, PowerShell - yes as it can use .Net libraries.
The fastest solutions for the languages you listed are named pipes and, better still, memory mapped files. Both have implementations in .NET 4.0 and unmanaged C++.
I would recommend looking into memory mapped files. It's relatively straighforward to create a file and an associated view that serve as single-producer, multiple-consumer, unidirectional channel. You can use, say, the first 4 bytes of the area to store the updated value of the last byte written (modulo the view size - 4 bytes) and an EventWaitHandle to synchronise producer/consumer access. Two channels accessing separate memory mapped files will give you a duplex channel.
Links for .NET (C# and VB.NET) and
unmanaged C++.
You may then want to look into Protocol Buffers as a very efficient way to serialise your binary data.
0MQ is an excellent product in the Linux space but the Windows version is somewhat stripped-down, and among other things doesn't support IPC.
There are different libraries you can try such as OpenDDS, ZeroMQ and others. Though ZeroMQ on Windows does not support IPC yet (but supports TCP).
I've got a Win32 C++ game side project and I'd like to create a C# process that can be dynamically attached. The C++ process could then send debug data to the C# process and the C# console could send debug commands to the C++ process. I know this can be done, but I'm not sure how to do it. Anyone know?
There are plenty of ways to communicate cross-process. For your purposes, I would recommend you use Sockets to communicate between the two, as this will also allow you to communicate between machines if you like; and the semantics of using Sockets are similar in both languages.
On the C# Side, you can get started with Sockets by using the Socket or TcpClient class in System.Net.Sockets. Also, you'll probably find it a little bit easier to implement the server / listening side in the C# process.
TcpClient Class # MSDN
Socket Class # MSDN
System.Net.Sockets Namespace # MSDN
On the C++ Side, you have two means of utilizing sockets, either via WinSock functions or Unix/POSIX style functions.
Getting Started with Winsock # MSDN
Winsock Functions # MSDN
Note that the WSA**** functions are the formal WinSock functions, and select/listen/bind/... are the traditional Unix/POSIX style ones. You can use one set or the other.
TCP Sockets are probably your best bet; but you may find that UDP allows you to get started quicker. Also, you could potentially do interesting things with UDP multicast. Don't forget to check your firewall settings if you use sockets.
Other possible means of communicating between the two involve varying amounts of work and domain knowledge that you may need to learn. Here's a brief outline with Pros and Cons.
Named Pipes
Pros: Excellent performance on the same machine, easy to control in C++.
Cons: Difficult to use across machine boundaries.
COM Application Server
Pros: Easy to consume on the C# side. Once created, easy to extend on the C++ side.
Cons: Can be difficult to debug, and it is tricky to add support to an existing project. Also prone to COM registration and debugging headaches. Difficult to learn to use across machine and user-session boundaries.
Shared Memory
Pros: Superb performance, easy to control in C++, moderately easy to control in C#.
Cons: Cannot be used across machines. Has quirks in sharing buffers across processes, though you can always create a buffer for each side, and make communication one-way for the buffers. This is tricky to use if you have more than 1:1 communication between your apps.
We are doing something very similar using named pipes in one of the projects that I am working on. Although I didn't work on the implementation it seems to be doing the job very well. The following link gives a good overview.
http://msdn.microsoft.com/en-us/library/aa365590(v=vs.85).aspx
I'm starting to write a program which communicates with serial/parallel ports. I'm not sure whether I should write it with C# or C++.
I prefer C# because it's my preferred language and I have written applications (high level) with it. But I'm not sure if it can handle port communication in all circumstances. (For example once I wanted to develop a filter driver and found out it couldn't be done at all using C#. So I'm in doubt about port programming limitations as well.) Usually people go with C++ in these situations. (why?) Is there any limitations in C# I should be aware of regarding this matter?
Since you need fine control over the port (ie, the ability to bit-bang and send raw data), then you need an extra component to do this in .NET. See http://www.lvr.com/parport.htm for an example.
There is no managed way to do this, but by using external components, you can develop in your familiar environment. This is probably the way to go, since dealing directly with ports is a life-consuming process.