I don't know if you can read, but I've already answered... Read the whole topic before you say stupid things like that.
EDIT: What I said was just a suggestion about how he COULD do it. I've ABSOLUTELY NOT said "this is the best solution". It's the solution how I should do it with my skills and my understoodings about his issues. But if there are better solutions, no problem for me! I have still to learn, but it's not needed to slap me down. Everybody here has ever started with something where there were better solutions for? Or was you a pro from the first day on?
Last but not least a quote from the rules: "Let's work to help developers, not make them feel stupid.."
Again, you never asked the question, so that really doesn't apply to you. If someone asks a question, and another gives an answer that is wrong, or clearly not what is desired, then a 'slap-down' is necessary. You didn't ask for the help, so there is no help for you given. I'm not making you feel stupid either, I think you are accomplishing that on your own.
Struggling to adapt a C++ pattern to C#. How do I get a WaitHandle from an IntPtr, which is the underlying socket handle to use in the socket thread as outlined below? I know there are Aysnc socket varieties but I'm keen to reuse this if at all possible. *** indicates the problem area in code
AutoResetEvent evtHalt = new AutoResetEvent;
Socket socket = new Socket(...);
WaitHandle handles = new WaitHandle(2);
// set up handles
handles = evtHalt;
// *** Nope *** conversion problems -
handles = socket.Handle;
Int32 ret = WaitHandle.WaitAny(handles);
if (ret == 0)
// cancelled as evtHalt was signalled
else if (ret == 1)
// socket signalled ... do something
Why don't you want to use the built-in .NET socket stuff? It's so easy it's downright sinful.
We have a proprietary client/server protocol and a diagnostic tracing facility built on top of TCP/IP sockets. The original code, written in C++, probably has close to a man-year of time on it. I replicated both of them in C# in a couple of weeks.
Sometimes you want to wait for other things than socket handles. It's common to have EventWaitHandles for signalling conditions to threads. If a thread needs to monitor both sockets and events, then one must find a way to do it the "C++ way". Still looking.
I'm comp.engineering student making a project for company having about 1600 PCs, my task in this software is to collect client PC hardware info and then send it to server,compare ,then to database.
I have already made a console application which extracts hardware info through c# . Now I'm making a GUI based app which would be running on server.
Well I'm thinking of asynchronous sockets for accepting incoming connections would that be OK ?
Also how should i enclose the info from client and send it to server where it is compared to data from SQL server and then committed if relevant . Is XML used for this purpose ?
And yeah also the company people say that need a feature on server that would allow the server to pick this hardware info from any client(s) at that particular instant . Would that require a listener on client side as well ? as i plan to disconnect client as soon it sends the relevant data ?
I'm sorry for my noobish questions as I'm new to this type of software as i have been bit more on hardware side Thanks in advance !
*EDIT* i forgot important thing! and that is the software would not be connected to internet in anycase! whole thing is on the network
Well, there are many ways you could do the job.
Using sockets directly or using Web Services.
Web Services will do the job for you and, internally, they use XML. If you use the sockets directly you will need to build the message, so you can build it in XML, or you can use the BinaryFormatter (my preferred one).
The biggest problem is that "need a feature on server that would allow the server to pick this hardware info from any client(s) at that particular instant". To do that you will really need to keep your clients connected.
The software would not be connected to web at all . so in that case what is better ? sockets (i have programmed them before ,so it won't be a big problem i guess) ? XML ? Binary (Why do you prefer it ) ?
How much network bandwidth would 1200-1600 TCP/IP client programs connected would cost ?
Well, using sockets you will still need to use binary/xml or other format.
I usually prefer BinaryFormatter (binary data) as it is smaller and generates less traffic. But, about the cost of 1200 to 1600 programs connected I really don't know the information.
But, if they don't send information all at the same time, I think it will not be a problem at all.
What kind of hardware info? Most such info doesn't change often, and not while the computer is running. How about a small program that gathers and sends the information at system startup? I would likely write the server side with WCF (mainly because I'm just learning it now).
pick this hardware info from any client(s) at that particular instant
I don't see why, unless it should know about USB devices and such.
Hardware info like Processor ,RAM , Hard-disk and others , i have already made the program using C# and relevant classes . Yes I'm also thinking to make this program run on the start-up
Yes the company wants to detect the removable USBs as well! so can you tell me how much would bandwidth 1200-1600 inactive TCP/IP connections would cost? its the only way to keep them connected all the time i guess
allScriptImage[e.RowIndex] = new Byte[scriptImage.Length);
allScriptImage[e.RowIndex] = scriptImage;
You have declared allScriptImage as having two dimensions but you have not reserved any space for it. I'm also not sure what you expect the above two lines to do since you assign a buffer to the entry and then immediately replace it.