Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I am getting a headache with standard socket class of .NET framework.
Could anybody recommend an efficient open source C# sockets (TCP + UDP) library for handling socket messages?
Use Kerry Jiang's SuperSocket library or Akka.NET
SuperSocket nuget package has over 100k downloads; note that 2.0+ is for .NET Core, whereas 1.6 is for .NET Framework 4.8 and below
SuperSocket.ClientEngine.Core has over 700k downloads
Akka (for .NET) has over 1.2M downloads, and has a special Akka.NET.Test
In a sense this is cheating because it postpones the decision of using sockets to the last moment
"Akka" started out as a Java/Scala project and was later to .NET
Therefore, you should Google search for "Akka.NET" instead of just "Akka"
In general, you probably want to construct your Network IO with some solution for back pressure, which you can do with Akka Async Streams in C# 8.
RSocket is a new library built by ex-Netflix engineer Robert Roeser.
Similar to Akka Streams in that it provides a way to handle backpressure.
Separately, in terms of using message queuing libraries instead of socket libraries:
EasyNetQ nuget package has over 4M downloads
NetMQ nuget package has over 600k downloads
ZeroMQ nuget package has over 80k downloads
I've used this in a real world project and it works fine, but it's a binding wrapper around a C dll
NetMQ is great for simple socket communication. It handles the reconstruction of messages and much of the messy details. It's meant for message communications as in a messaging system, but it would work great for simple sockets. Take a look at Request-Response. Sockets are one of the areas where you do often end up with framework on top of framework, regardless, let NetMQ handle the nitty gritty.
Take a look at WCF which is included in .NET.
I made sample application in for console/win app based C# WCF/TCP socket server/client here
https://github.com/evaldsurtans/wcf-sample-server-client
The .NET framework is already a library for handling tcp and udp. It simplifies the process greatly over the base winsock apis. So you want a library that sits on top of the library? Maybe you would then want another library on top of that? And another on top of that one?
My point is, you're likely not going to find anything simpler than what the .net framework already provides. Sockets are a complex topic, and requires that you provide a great deal of implementation yourself.
What a library is often useful for is implementing some already established protocol (like SMTP or FTP), or maybe even giving you more tools to create your own protocol.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
UPDATE:
1 - New C# application exposes NamedPipeServerStream(System.IO.Pipes) on .Net framework.
2 - Legacy VB6 needs to communicate with the C# NamedPipeServerStream.
3 - Until now VB6 resides in a system without .Net framework. But, going forward both C# and legacy application will be on a computer which has .Net installed.
3 - Can VB6 talk to the C# pipe server using CallNamedPipe() and is this approach hassle free in maintenance of the communication betwen the applications?
Any resources I can look into or other approaches ?
Old question:
I have a legacy VB 6.0 application which needs to communicate with a newer C# application using .Net NamedPipes.
Currently, the legacy VB6 application sits on a system without .Net.
When I install .Net framework and the C# NamedPipeServer application on that system, how can the legacy VB6 program communicate with the C# application over NamedPipes ?
Please let me know.
Thanks in advance.
I have worked with a VB6 application which needed data from a set of WCF services.
The easiest way to achieve this is to put the logic to communicate with remote systems in a .Net assembly which exposes operations via COM and call that assembly from your VB6 code.
See https://msdn.microsoft.com/en-us/library/system.runtime.interopservices.comvisibleattribute(v=vs.100).aspx as a starting point.
If you are using System.IO.Pipes for this then thankfully you don't have to deal with the cruft and interoperabiity nightmare known as WCF.
To write a nice pipe client in VB6 requires a control or class written in C++ in order to manage the async I/O and raise events. Otherwise you will probably have to use a Timer to poll for input, but it is all fairly straightforward API I/O then.
I don't know of any cheap or free ActiveX DLL or OCX generally available today, and I doubt Microsoft ever produced one. But the Timer-driven polling approach should have plenty of examples out there to get you started. And it spares you the terrible inefficiency, stops and sputters, and giant memory footprint of saddling your VB6 program with all the overhead of using .Net Interop.
But that is always an option.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I'm new to C# and decided to write a small client server chat application to approach the new language with learn by doing.
The question I have now is whats the best way to code the server part on.
The client is built with C# and for now a MySQL connection to my hosting server(Linux).
But i realized this is a dumb way to go at it.
So I was thinking of writing a server part that all clients connect to and that server will have a MSSQL connection and handle all the requests and chat delegation.
So the options I'm thinking about is either
WCF Service (as I understood they can be installed on any IIS server)
Windows Service (don't know if you can run this on hosts online)
ASP.NET WebService (This would actually only by a website that takes requests)
Node.js with socket.io
Other options?
What do you guys think would be the best approach for his?
To keep in mind is that I would like this server to be hosted online without spending tons of money on a VPS-Server or similar.
As the most productive solution, you should probably go with SignalR (http://signalr.net/), or ServiceStack (https://servicestack.net).
Both "frameworks" are fully mono compatible, so you can run the solution you build on your linux-server.
As an ORM-Mapper, you could use the EntityFramework, which would allow you to use not only your linux-server, but also your MySQL-DB. See this blog-post for more details: http://blog.3d-logic.com/2013/04/14/entity-framework-6-on-mono/
Depending on your "other language"-knowledge, you want probabbly to start off with no framework at all, but to build everything from scratch.
Maybe it was just me, but I learned the most about how .net works, as I had to "rebuild" stuff like linq, etc.
You can also consider:
ServiceStack
ASP .Net Web Api
Windows Service is not a technology, it is may be using as host (IIS, Windows service)
The easiest way to get started is to stay in the Microsoft walled garden and adhere there their ideas about how this should be done. Microsoft developer products integrate exceptionally well.
Probably a console application connecting to a WCF service connecting to a SQL Server using Entity Framework.
This is rather straight-forward to set up. Tutorials for this are available in heaps. Make sure to use recent tutorials and try to stay simple.
I advise against writing a chat because that requires either polling or a push mechanism. I think that is unnecessary for a beginner project. Write a data-driven application like a to-do list. Get fancy later. The first steps are hard enough.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I see there are some other posts related to this issue. However, I want to ask if there is new elegant way to just exchange some messages between a C#.net application and a C++ application?
They are running on the same machine.
Thanks in advance.
What you want is inter-process communication (IPC), which is language-agnostic by definition.
Typical solutions include:
Named pipes (also called FIFOs)
Mail slots
File mapping
Sockets
RPC
etc.
You use different ones depending on your needs.
Here is information on windows-supported IPC methods: http://msdn.microsoft.com/en-us/library/windows/desktop/aa365574%28v=vs.85%29.aspx
Most of this functionality is exposed in C# through WCF, which is windows-specific of course. If you're using Mono, you're out of luck.
C++ doesn't define any IPC constructs in the language itself, so you will have to use platform-specific libraries regardless.
Search around for IPC examples in C# and C++ and you will get plenty of hits.
Here's a SO post to get you started: IPC Mechanisms in C# - Usage and Best Practices
I have always used sockets, that is the simplest way I can think of (not the most elegant though)
There are many mechanisms you can use to do this.
This article enumerates the common ways to accomplish interprocess communication on the windows platform. Most if not all are possible form both C# and C++ (though I would hate to see you use DDE from C#, though it has apparently been done).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
Overview
I am sending messages back and forth between a client (Android phone) and a Server (Windows Server). Using a persistent connection over TCP, which protocol would be the best solution. I am looking at performance, scalability, size of messages, and battery life. The messages must arrive at the destination in order and can not be duplicates.
MQTT
This seems like the better solution, but there seems to be little examples of large implementation with lots of users. I am not sure if I can integrate this into the windows server, or if it would have to be another application or server running. Finally there seems to be a lack of information on it in general.
XMPP
This seems to have lots of implementation, examples, and even a book : ). However the main purpose seems to be for instant messaging clients and things like Google talk. Will this be an optimal solution to messaging between server and client. I know currently XMPP is mostly used in client to server to client architectures.
Please correct me if I am wrong and thanks in advance for any guidance.
It depends on what you are trying to do and what hardware you are running.
MQTT has very low keep-alive traffic. XMPP is a an IM protocol, and has a much, much higher overhead in handling presence messages between all the clients.
If you have a small memory footprint constraint, then having to handle the XML parser may make the use of XMPP impossible.
Keep in mind that MQTT stands for Message Queue Telemetry Transport, i.e., it is a transport protocol and does not define the message format at all - you will have to supply this; XMPP is an Instant Messaging protocol which carefully defines all the message formats and requires that all messages be in XML.
In addition to all this: MQTT is a publish subscribe protocol, XMPP is an instant messaging protocol that can be extended (using XEP-0060) to support publish subscribe. You need to consider this when you architect your system.
We are finding MQTT to be the quiet achiever. Your milage might be different.
It all depends ...
Track down the recent announcement by LinkedIn where they discuss their use of MQTT in their mobile app.
Cheers
Mark
(BTW Andy was slightly off in his reference to us. We are at Centre for Educational Innovation & Technology (CEIT), The University of Queensland, Brisbane, Australia)
I think that in short the MQTT advantages over XMPP are:
Throughput capacity: less overhead, more lightweight
Binary vs plain text
QoS in place (Fire-and-forget, At-least-once and Exactly-once)
Pub/Sub in place (XMPP requires extension XEP- 0060)
No need for an XML parser
I think you are probably correcting your assessment of XMPP in that it is a primarily chat-oriented protocol - it is also quite heavyweight and uses XML extensively making it verbose. I know that folks at CEIT at the Uni of Brisbane have specifically studied the differences and optimal uses for the two protocols. MQTT is very lightweight and low power - it has been used for telemetry and sensor applications for over 10 years and has been deployed on a very large scale by IBM and partners. Folks are now finding that a simple protocol like this is ideal for mobile development.
What exactly are you looking to achieve? The mqtt.org site aims to provide good links to content. There are also IRC channels and mailing lists about it. How can we help?
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I have little experience in C#.NET, but have years in Delphi. Any Delphi + .NET people out there that can provide me some guidance?
Here's the scoop:
I am going to be in charge of a overhaul of the codebase (200,000 lines+). We're going to be creating a full n-tier architecture, with the front end being Silverlight. We chose Silverlight as the front end because it can be deployed in a browser as well as an application with minimal effort, from my research.
I have not been able to find a clear comparison between Remobjects SDK and WCF. The few threads I encountered mention the issues with WCF, such as response times, large overhead, and somewhat snotty responses from MS.
This question is more for the backend. Our current codebase is in Delphi. Is it worth keeping the backend in Delphi, if at all possible? The debate is between using WCF if moving to .NET, or using Remobjects SDK (.NET and Delphi flavours simultaneously) if sticking with Delphi.
Pros of Delphi backend + Silverlight frontend:
Existing codebase: Less time during migration
Existing Knowledge: Developers familiar with our codebase are already familiar with Delphi
Easy Deployment: The single exe/dll deployment is difficult to ignore!
Cadence: The Remobjects SDK has been solid for years
Cons of Delphi Remobjects SDK backend + Silverlight + Remobjects SDK frontend:
Technology: Is it even possible for Remobjects .NET to communicate with Remobjects Delphi with Session functionality?
Knowledge: Other that our few developers, the knowledge of delphi is very thin in our city area.
Project code re-use: We would need to re-develop classes in C# as well as Delphi for use in Silverlight.
Cost: Additional cost in licensing
Future: hard to say when Delphi will collapse
Now for the WCF .NET..
Pros of WCF .NET backend + Silverlight frontend:
Project code re-use: A class can be used in both the backend and frontend
Technology: Its already proven
Knowledge: Our city area loves .NET, so there is lots of talent available to hire.
Future: Everyone knows that MS is making tons of money off .NET and VS 2010. This adds some stability to the .NET architecture.
Cons of WCF .NET backend + Silverlight frontend:
Existing Codebase: Our entire codebase would need to be redone, aside from class structure references.
Deployment: I myself have not deployed a WCF application, but I know its more complicated than Delphi.
Cadence: Microsoft is notorious for changing the game as soon as the industry settles. Happened to COM, when will it for .NET?
What would be the ideal situation? After writing this all out, its looking like C# backend is the winner, due to the lower costs and higher chance of a stable future. Whichever backend we use now will be the method of choice for all projects in the future.
What are your experiences with implementing your WCF n-tier application?
Are there clear any clear and concise books / articles that outline WCF's usage, and best practices when designing your application?
Is there a better solution than WCF in this situation?
Sound off your thoughts!
Joel on Software has a pretty good article about rewriting from scratch (http://joelonsoftware.com/articles/fog0000000069.html). I'm not sure if that completely applies to your situation, but the gist of his article is don't rewrite, ever. You have years of work and bug fixes already in that code, and rewriting it in another language simply won't be able to cover all of those fixes. My recommendation would be to find a good way to interface your Delphi back-end with the new Silverlight front-end. That being said, I've never done any interfacing with Delphi, so you're on your own from there.