As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am writing an application in C#, that will be Compiling and Executing external code written in either C, C++ or Java. In this regard, I have a few questions to ask and following is the research that I have done so far:
There will be a server that will host the application that will receive requests of code submitted by users. These requests will be sent on a particular socket.
There will be a receiver thread that would en queue all such requests into a queue.
There will be consumer thread that will dequeue from the queue and compile and execute the programs (submitted code). While compiling and executing, appropriate compilers and loaders will be used from the command line, which will be executed as processes from the C# App.
As of now, it can be assumed that security issues such as sandboxing, not making the server access public, etc have been / will be considered later. My primary focus is on this execution logic.
I have the following questions to ask:
Can there be a better way of doing this / Am I doing anything wrong?
Approach looks good on paper, but it mostly depends on the implementation.
As many as you want, up to the capabilities of the machine. OS will handle them.
It doesn't really matter as long as you make it airtight: malicious/malformed/plainly wrong code will be submitted: Java can't do that much damage, but C/C++ is kinda dangerous.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am someone migrating from a C++/Win32 development environment to C#/.NET. One thing that I have noticed is that mostly erroneous states are handled in C++/Win32 by the use of error codes and their propagation.
To the contrary most erroneous states in C# /.NET seem to be handled by the use of exceptions and error codes are seldom advised to be used.
Why so?
The main issue with error codes is that one needs to check them. Always.
And we are only human and can forget.
This can mean we can get our programs into inconsistent state by simply forgetting to check an error code.
If we forget to handle an exception, though, our program will exit.
This is seen as preferable to it continuing to run in an inconsistent state.
Much of the reason that error codes are still prevalent in C/C++ code is historical - these languages didn't have exception handling, so needed error codes. And there are many libraries and code out there that conforms to this idiom, so programmers need to keep with it.
There are other reasons to use exception apart from the fact that they cannot be ignored - they carry quite a lot of context, as Marc observed - stack traces, messages and more, beyond the type of the exception.
One of the major reasons I'd say is that error codes are platform specific. .NET was originally designed to be portable.
For example a FileNotFoundException is more universal than some obscure number that may vary depending on what platform you are running on.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Recently i read an article which said something similar to "stop using classic approach in web development where server gets data from any datastore and renders the views to browser. server must only retreive needed data end response it via json or whatever so client can render it as he wants". Obviously this approach decreases network traffic + page load would be faster. But on the other hand we have to write more JS code(like Knockout). What's your opinion? What problems can appear in this case?
The advice is valid, but should be less dogmatic. The reason to switch to a data-fetching approach is pretty simple in reality: it allows you to reuse the calls elsewhere, if you have multiple parts of an application requiring the same data. Depending on how you do it, though, you might run into increased bandwidth usage due to not being able to get exactly the data you want in one AJAX call (thus duplicating/splitting requests).
The other obvious advantage is it allows you to roll out an outside API pretty easily once that is done.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I need to have a file synchronizing feature in my .NET application. Can I make use of rsync? Is there any API available?
There is a C# implementation of RSync on github with some recent commits:
http://github.com/MatthewSteeples/rsync.net
DeltaCopy is just a wrapper around the rsync executable. However, librsync itself can be built on Windows as well as UNIX and GNU/Linux (see their README and this EE thread). Thus, that's another option to consider. You would still need some kind of unmanaged-managed interop.
You can use the source code that comes with DeltaCopy, which is a "'Windows Friendly' wrapper" to the original RSync.
The source is written in c++, so it's not exactly .Net, but you can write managed C++ wrappers and use them.
It's not a direct solution, I know, but it may be somewhat helpful. (in other words, HTH)
If you are looking for some simple automation you could just write a tiny wrapper that invokes RSync via System.Diagnostic.Process
I did read somewhere that someone circa 2006 created an rsync port in C#, but to be honest with you I would not consider using it cause its far from popular and impossible to find.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
use net remoting or others ??
I want sample way, I think that no socket or other would be more easy to deploy ...
anyway ,help please , thanks.
You will want to begin with Namedpipes.
Since you are dealing with C#, have a look at:
http://msdn.microsoft.com/en-us/library/aa365590(v=vs.85).aspx
Essentially, this got me going instantly when I was looking into it:
http://msdn.microsoft.com/en-us/library/bb546085.aspx#Y1920
Good luck.
It depends on what you want to do. If you just want to send notifications between two processes running on the same computer, named events work just fine. If you want to send long messages, then there are named pipes, sockets, and WCF (which replaces .NET Remoting). You might also want to share memory with memory mapped files. There are several other possibilities.
The method you use depends in large part on how much data you want to communicate, how fast you need it to be, and how much time you want to spend futzing with it.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm doing a little research in developing a simple socket server that will run as a windows service. I'm going to write this in C#, but I've been made aware that .Net sockets are slllooooowwwww. For the initial roll out using the .Net Networking classes will be fine, but I'm wondering if anyone has experience with a high performance (and hopefully free) socket library. I'm thinking probably something written in c++ that I can use as a com object in .net.
I've used indy sockets before, but it doesn't look like there is any active development going on with the project anymore. I've done some googling and I've found a few libraries, but I was hoping to get feedback from someone who has actually used a socket library with good success.
Any help appreciated. Thanks.
I would revisit your initial assumption - I don't believe it's accurate.
In my experience, the overhead of using .NET's framework socket libraries is not high - they perform quite well. The main cause of very slow socket code, that I've seen, is when people try to port non-C# code into C# directly, in particular, trying to port synchronous C++ socket code. The sockets in .NET's BCL are all designed to be used asynchronously. If you try to force them into a synchronous model, you'll end up adding quite a bit of blocking, which definitely causes very slow code.
Try using the socket classes the way they were designed - I think you'll be very happy with the performance, as well as the usability.
Sounds like you are optimizing before you need to. I would go ahead and build it with .NET and see if you have a performance problem before you try to do something that would potentially be slower. COM has a lot of overhead.