I have implemented a C library and would like to expose its functionality to a UI. The UI will either be a Windows Forms UI or a WPF UI.
To come up with a more "platform independent" way of tying the UI and the C lib together, I have thought about creating a socket on the UI side as well as on the C-side. The socket will be used for exchanging bi-directional messages between the UI and the library. I know that there might be some overhead to doing it in this way, but the "message traffic" between the UI and the C code is not going to be heavy.
Another reason for doing it this way, is because I've read that there are so many pitfalls that you have to be aware of when you use PInvoke, IJW, COM or CLI (for enabling C#-to-C calls and C-to-C# calls). This socket-approach makes it more clean and I'll have better control of what's actually going on when the C# code sends a message to the C code (or the other way around).
To get started and to avoid wasting my time, I'm looking for some advice from seasoned developers who know a lot about socket code.
I'm not sure about what the requirements for the socket code on either side should be? I do know that I want any component on the UI side to be able to send and respond to messages.
Using sockets will require your c program to become a server, which opens a socket and listens. Upon receiving a request it does some stuff and typically returns an answer. The idea is communication between networked computers.
here is a basic example. http://www.linuxhowtos.org/C_C++/socket.htm
Writing socket code requires compatable data formats between the sending app and receiving app. This means you need to carefully structure your messages and ensure that each integer, long integer, float, double and fixed length string exactly match. An extra byte on 1 side will scramble your message into junk. If your c and c# data encoding formats mismatch - you will have extra decoding/formatting work.
I preferred to use ONC-RPC to write client server code between inequal systems. A decade ago I used RPC to connect big endian Solaris to a little endian VMS system - it worked flawlessly, it was really quick to write.
I'd avoid writing low level socket code because it's time consuming and difficult, except when you need high performance networked apps.
Related
I have a problem, have not much experience in C #, so I did a lot of research and I'm stuck.
I have to make two applications C #, the first applications is windows forms, the second runs in the background, so that the first applications will be a (POS) sales point that need to communicate with the application background for information as (products, customers, etc ...) and send data, so do not want to use web service for problems like timeouts, so anyone can help me with some idea to perform this task?
it is important to mention that the application in background will be just one while the POS applcations wich will communicate with it will be a lot (n number of apps).
There is a myriad of ways of doing interprocess communication. As the question is so generic, I will point out some more common ways.
The background process can be a windows service which updates the DB and POS systems query the DB to retrieve what they need. Even if the background process reads from the same DB, you can have a separate table which has "finished" information ready for the POS piece to pick up. Now you can use a file instead of a DB to store this finished results too, but most folks prefer DB.
You can use WCF channel to establish communication between the POS piece and the background process.
You can convert your background process to a web-service and let your POS piece communicate using XML. I don't think any time-out issue should be a problem. You will have to explain better what time-out issue causes you to not use this option.
You can convert the whole piece into a web-site and the POS will simply be a browser then
You can use a bus like Tibco or MQ to pass data.
Or you can go the old fashioned way of TCP sockets.
The most preferred way is usually the web-servcie or web-site way depending on your constraints.
Typically you'll use a message queue for something like this. They are a component in ensuring clean separation of concerns reducing and cross-application coupling and are meant to receive messages by some publisher (thus freeing the publisher of any further responsibility), and pushing messages to some subscriber.
RabbitMQ is a popular framework: https://www.rabbitmq.com/
(note that RabbitMQ (and other ready-built frameworks) can sometimes be daunting for new application programmers as they handle a great many use cases. However the underlying concept of writing to a queue from one application and reading from the queue in the other application is really the key here... feel free to implement a small utility of your own as a learning experience, but I do recommend an pre-existing framework if you're comfortable using such)
One method is to use named pipes for such communications between different programs.
How to: Use Named Pipes for Network Interprocess Communication
If you do not want to use web service (based on soap protocol),
you could attempt to use web api. In this way, you could build rest based interfaces with json (json streaming between computers is faster than xml streaming).
I think the following link can be usefull to you:
http://www.asp.net/web-api/overview/getting-started-with-aspnet-web-api/using-web-api-with-aspnet-web-forms
I've worked on a program that uses databases to send small messages from one PC to another. What I've done is put the database in a shared folder, have the program on the other PC connect to it (via a Path, no less), and there it is, a simple and easy way to get messages to and fro PCs on a network. Not the best option, but it's just homework, and the quick and dirty approach got me a grade.
But now the homework is done, and I'd like to improve upon what I did. The problem with the program is in the deployment stage. There are too many folders / installation paths and administrative / sharing issues regarding pathing directly to a database on a shared folder.
So the good folks here in stackoverflow advised me to try Socket Programming, which I think is a bit out of my league. But you never know...
Also, I'm aware of the difference between Sync and Async socket programming. One blocks, the other doesn't. The program I'm working on is a simple turn-based game, so I thought Synchronous might be good enough, since if it's not your turn, you really can't do anything. The issue however is that the program is treated as "not responding". I tried asynchronous, but ran into problems with threading, something I consider WAY out of my league.
Logically, the program is simple. One host, one client. Upon client connection, host sends data. Then client receives, send out its own data. And so on, until one player loses.
I'm sorry to say only .NET 2.0 is installed in my school. No WCF or anything. Also, it must be done in C# Windows Forms, so XNA is out.
So, I'd like to ask... is there an easy way to get into Socket Programming? Any guides / sample projects that can help? Pre-made codes that can be studied, and adapted?
Majority of the samples I found and adapted are chat applications, which I thought good enough, but making it modular simply breaks it.
The chat application examples you encountered should be enough. It is not clear to me what you refer to as "making it modular".
What you need is to design a protocol to be sent over the connection, an agreement of rules so to say, so that one knows what the other is talking about. So instead of sending plain text (chat) you can send the following:
0x03 (length of the message)
0x0A (move command in this fictional protocol)
0x02 (parameter 1 of the command, X coordinate in this case, it's all defined in the protocol design)
0x05 (parameter 2 of the command, Y coordinate in this case, it's all defined in the protocol design)
Now it's entirely up to you what happens after you received and interpreted the data. Personally I would go for the Async solution, since it leaves your program to do other stuff (graphics?). And it's more easily adaptable in code, in my experience.
I've made some classes which can be used to transport objects over a socket using the BinaryFormatter.
Here are some tests for my BinaryTransport class:
http://fadd.codeplex.com/SourceControl/changeset/view/67972#1055425
The actual class:
http://fadd.codeplex.com/SourceControl/changeset/view/67972#1054822
Do note that it's a while ago that I wrote them. I just noticed some small bugs. But either use them or just study the classes to learn more.
I remember when I started with socket communication in C# I tried to implement a simple chat program between a client and a server and then between multiple clients. Here is the tutorial that I was reading then: http://www.codeproject.com/KB/IP/TCPIPChat.aspx
If you want the full code I can upload my final project and you can study the code. It also uses multithreading so you can see how to handle this situation in GUI applications.
Side note: Wow, that database idea is the craziest thing I've seen in terms of PC-to-PC communication. Well done!
One interesting, useful and easy exercise you can do to learn about sockets (which C# makes it easier even) was creating a TCP-based logger.
During development every programmer needs a way to know what's happening under the hood at certain points. Without a logger you would normally write something like:
Console.WriteLine( "blah" );
which results in a dull, unfiltered, unorganized string thrown to the output window.
I created a TCP-based logger very easily using sockets. In one hand you have a separate Winforms application (the server), which is in charge of listening to incoming messages and beautifully displaying them on a rich-content control. In the other hand, you write a very simple class (the client) with a single function like:
public static class MyConsole
{
public static void WriteLine( string message, string whatever )
{
// send to the net
if( mTcpSocket.Connected )
mTcpSocket.Send( message );
// in case the server is not there we still have regular output
Console.WriteLine( message );
}
}
I created this logger once and have been using it ever since. Furthermore, given its tcp nature, with minor changes on the server side I've been successfully using it from different languages, as C# and Java, and now using it from ActionScript.
The requirement of the TCP server:
receive from each client and send
result back to same client (the
server only do this)
require to cater for 100 clients
speed is an important factor, ie:
even at 100 client connections, it should not be laggy.
For now I have been using C# async method, but I find that I always encounter laggy at around 20 connections. By laggy I mean taking around almost 15-20 seconds to get the result. At around 5-10 connections, time to get result is almost immediate.
Actually when the tcp server got the message, it will interact with a dll which does some processing to return a result. Not exactly sure what is the workflow behind it but at small scale you do not see any problem, so I thought the problem might be with my TCP server.
Right now, I thinking of using a sync method. Doing so, I will have a while loop to block the accept method, and spawn a new thread for each client after accept. But at 100 connections, it is definitely overkill.
Chance upon IOCP, not exactly sure, but it seems to be like a connection pool, as the way it handles tcp is quite like the normal way.
For these TCP methods I am also not sure whether it is a better option to open and close connection each time message needs to be passed. On average, message are passed from each client at around 5-10 min interval.
Another alternative might be to use a web, (looking at generic handler) to form only 1 connection with the server. Any message that needs to be handled will be passed to this generic handler, which then sends and receive message from the server.
Need advice from especially those who did TCP in large scale. I do not have 100 PC for me to test out, so quite hard for me. Language wise C# or C++ will do, I'm more familar with C#, but will consider porting to C++ for the speed.
You must be doing it wrong. I personally wrote C# based servers that could handle 1000+ connections, sending more than 1 message per second, with <10ms response time, on commodity hardware.
If you have such high response times it must be your server process that is causing blocking. Perhaps contention on locks, perhaps plain bad code, perhaps blocking on external access leading to thread pool exhaustion. Unfortunately, there are plenty of ways to screw this up, and only few ways to get it right. There are good guidelines out there, starting with the fundamentals covered in Rick Vicik's High Performance Windows Programming articles, going over the SocketAsyncEventArgs example which covers the most performant way of writing socket apps in .Net since the advent of Socket Performance Enhancements in Version 3.5 and so on and so forth.
If you find yourself lost at the task ahead (as it seems you happen to be) I would urge you to embrace an established communication framework, perhaps WCF with a net binding, and use the declarative service model programming of WCF. This way you'll piggyback on the WCF performance. While this may not be enough for some, it will get you far enough, much further than you are right now for sure, with regard to performance.
I don't see why C# should be any worse than C++ in this situation - chances are that you've not yet hit upon the 'right way' to handle the incoming connections. Spawning off a separate thread for each client would certainly be a step in the right direction, assuming that workload for each thread is more I/O bound than CPU intensive. Whether you spawn off a thread per connection or use a thread pool to manage a number of threads is another matter - and something to determine through experimentation and also whilst considering whether 100 clients is your maximum!
I'm thinking like the methods games like Counter Sstrike, WoW etc uses. In CS you often have just like 50 ping, is there any way to send information to an online MySQL database at that speed?
Currently I'm using an online PHP script which my program requests, but this is really slow, because the program first has to send headers and post-information to it, and then retrieve the result as an ordinary webpage.
There really have to be any easier, faster way of doing this? I've heard about TCP/IP, is this what I should use here? Is it possible for it to connect to the database in a faster way than indirectly via the PHP script?
TCP/IP is made up of three protocols:
TCP
UDP
ICMP
ICMP is what you are using when you ping another computer on a network.
Games, like CounterStrike, don't care about what you previously did. So there's no requirement for completeness, to be able to reconstruct what you did (which is why competitors have to tape what they are doing). This is what UDP is used for - there's no guarantee that data is delivered or received. Which is why lag can be such a problem - you're already dead, you just didn't know it.
TCP guarantees that data is sent and received. Slower than UDP.
There are numerous things to be aware of to have a fast connection - less hops, etc.
Client-to-server for latency-critical stuff? Use non-blocking UDP.
For reliable stuff that can be a little slower, if you use TCP make sure you do so in a non-blocking fashion (select(), non-blocking send, etc.).
The big reason to use UDP is if you have time-sensitive data - if the position of a critter gets dropped, you're better off ignoring it and sending the next position packet rather than re-sending the last one.
And I don't think any high-performance game has each and every call resolve to a call to the database. It's more common to (if a database is even used) persist data occasionally, or at important events.
You're not going to implement Counterstrike or anything similar on top of http.
Most games like the ones you cite use UDP for this (one of the TCP/IP suite of protocols.) UDP is chosen over TCP for this application since it's lighter weight allowing for better performance and TCP's reliability features aren't necessary.
Keep in mind though, those games have standalone clients and servers usually written in C or C++. If your application is browser-based and you're trying to do this over HTTP then use a long-lived connection and strip back the headers as much as possible, including cookies. The Tornado framework may be of interest to you there. You may also want to look into HTML5 WebSockets however widespread support is still a fair way off.
If you are targeting a browser-based plugin like Flash, Java, SilverLight then you may be able to use UDP but I don't know enough about those platforms to confirm.
Edit:
Also worth mentioning: once your networking code and protocol is sufficiently optimized there are still things you can do to improve the experience for players with high pings.
I'm an embedded programmer trying to do a little bit of coding for a communications app and need a quick start guide on the best / easiest way to do something.
I'm successfully sending serial data packets but need to impliment some form of send/ response protocol to avoid overflow on the target system and to ensure that the packet was received ok.
Right now - I have all the transmit code under a button click and it sends the whole lot without any control.
What's the best way to structure this code , i.e sending some packets - waiting for response .. sending more .. etc etc until it's all done, then carrying on with the main program.
I've not used threads or callbacks or suchlike in this environment before but will learn - I just need a pointer to the most straigtforward ways to do it.
Thanks
Rob
The .NET serialport uses buffers, learn to work with them.
Sending packets that are (far) smaller than the Send-buffer can be done w/o threading.
Receiving can be done by the DataReceived event but beware that that is called from another thread. You might as well start your own thread and use blocking reads from there.
The best approach depends on what your 'packets' and protocol look like.
I think to have a long experience about serial comm, both MCU and PC-based.
I strongly UNSUGGEST the single-thread based solution, although it is very straigthful for light-speed testing, but absolutely out for final releases.
Surely you may choose among several patterns, but they are mostly shaped around a dedicated thread for the comm process and a finite-state-machine to parse the protocol (during receiveing).
The prevoius answers give you an idea to how build a simple program, but it might depends on the protocol specification, target device, scope of the application, etc.
there are of course different ways.
I will describe a thread based and an async operation based way:
If you don't use threads, your app will block as long as the operation is performing. This is not what a user is expecting today. Since you are talking about a series of sending and receiveing commands, I would recommend starting the protocol as a thread and then waiting for it to finish. You might also place an Abort button if neccesary. Set the ReadTimeout values and at every receive be ready to catch the exception! An introducing into creating such a work thread is here
If you want to, use Async Send/Receive functions instead of a thread (e.g. NetworkStream.BeginRead etc.). But this is more difficult because you have to manage state between the calls: I recommend using a Finite State Machine then. In fact you create an enumeration (i.e. ProtocolState) and change the state whenever an operation has completed. You can then simply create a function that performs the next step of the protocol with a simple switch/case statement. Since you are working with a remote entity (in your case the serial target system), you always have to consider the device is not working or stops working during the protocol. Do this by starting a timeout timer (e.g. set to 2000ms) and start it after sending each command (assuming each command will get a reply in your protocol). Stop it if the command was received successfully or on timeout.
You could also implement low-level handshaking on the serial port; set the serial port's Handshake property to rts/cts or xon/xoff.
Otherwise (or in addition), use a background worker thread. For simple threads, I like a Monitor.Wait/Pulse mechanism for managing the thread.
I have some code that does read-only serial communications in a thread; email me and I'll be happy to send it to you.
I wasn't sure from your question if you were designing both the PC and embedded sides of the communication link, if you are you might find this SO question interesting.