Advanced Winsock2 Question.

[Kailin]

Greetings Gurus! Thank you in advance for your help.

Here is my situation:

- A server application on a remote PC is sending data to a client application (ClientApp1) on my PC on port 5636.

- I want to capture this data in another application so I wrote a second application (ClientApp2).

- The server app only allows one connection, so for ClientApp2 I have used winsock2 and set the ioctl of the socket that I'm using to SIO_RCVALL. If this terminology doesn't mean anything to you please look at: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/winsock/wsaioctl_2.asp.

- Using winsock2 and SIO_RCVALL in ClientApp2 allows me to successfully capture all the incoming data that I need and ClientApp2 never actually "connects" to the server application which is great.

- My problem is that SIO_RCVALL can only be used on computers that have Windows Administrator privileges. I need this application to work on all computers regardless of if you have administrator privileges or not. I need this to work if you only have "Power User" privileges.

Any solutions to this problem would be appreciated. Thank you.

[Paul Rice]

Can I ask if you've written both apps what is it the second client does that can't be done in the first app?

I might write one app to do it all, but, I might also use one app to connect to the server and receive and cache the data then make that data available to the other app.

[TheCPUWizard]

You have basically written a "port sniffer" or "port spy". Allowing this type of code to run is dangerous [if someone else is using it to spy on your data] so it's execution is limited to admin level users who "should" know what they are doing. This is a good thing.

Now your problem is quite common. Assuming you (or someone else there) has admin level access to install a program ONCE on the machine, there is a simple solution.....

[TheCPUWizard]

Oh I guess I should tell you what it is :D

Write the sniffer to run as a SERVICE that can be installed and started once. You can then write "client" code that will enable/disable the actual monitoring and connect to the datastream provided.

This is a fairly standard process and conforms to "best practices and procedures" for developing this type of code.
Good luck!

[Paul Rice]

Is that what he's doing? I missed it by a long shot! LMAO

[TheCPUWizard]

ClientApp2 is monitoring the data without establishing a connection. That makes it a spy, but does NOT make it a "bad thing".

Just wondering what is making you laugh.....

[Paul Rice]

I just couldn't figure out for the life of me what he was doing. Then it occured to me from what you wrote that maybe he didn't write the first app. I was confused.

[Kailin]

Paul and TheCPUWizard: Thanks for all your comments!

Paul: No, I didn't write the server app nor ClientApp1, they were written by a third party. I am in the process of writing ClientApp2. Sorry about the confusion.

CPUWiz: Excellent suggestion, writing a "SERVICE" app is probably a good way of solving this problem. Of course, I will have to rework my project a bit, but hey, that's programming for ya. Would you recommend I use "COM" to communicate between the "SERVICE" app and ClientApp2?

Thanks again Paul and CPUWiz.

[Andreas Masur]

[Moved thread]

[Mathew Joy]

There are a few problems with using SIO_RCVALL option. One thing is as mentioned, you need administrative previllage. Second is this command is available only with 2000 and later. Thirly I've read reports, using this method will not accurately recv all the data that has been passed. I do not know if this has something to do with not enough recv waiting, though using only one recv() in a single thread (ofcourse in a loop) will certainly lead to data loss. What you can do is to try more that one thread or better, use overlapped recv (using WSARecv()). Another thing you have to remeber is that you have to supply a sufficiently large buffer(theoretical limit is 64k).

A better approach, though fairly complicated, will be using lsp. Almost all problems said above (and that is mentioned in this thread) is solved. As said it is complicated (learning curve is high, you need good knowledge, hard debugging etc..)so think twice (better thrice) before you set out with LSP.:)

Hope that helped :thumb:

[TheCPUWizard]

Implementation specifics are dependent on the language you are using...If VC++ 6.0 then COM and a standard service, If .NET then an enterprise component, Other platforms research (although probably COM).

Matthews comments about the supported environments and limitations are also on-target. Since SIO_RCVALL does not create a full connection, there is the risk of: Data Loss, Data Duplication, Data Out of Order. This may be acceptable. LSP is one alternative.

If you can control the port for ClientApp1 (which you did not write, but "might" be configurable...) then implementing your program as a proxy might be a feasible alternative. If you can not control the port, but can control the server address, then you could implement the proxy on an independant machine. The proxy would give you reliable connectivity and assure the data was intact.

I had left these options out of previous posts based upon the (possibly incorrect) assumption that your existing implementation was functioning in a robust manner and the ONLY issue was execution rights...