Network data transfers to/from user mode

Thanks Pavel. But I guess I was not clear in my description: the issue is for processing AFTER it has been received on the socket. It needs to go through a user-mode “protocol” module before sending out on h/w. Thus the potential need for pending requests from that user-space module.
Thanks!

So you have two user-mode softwares, software A is sending data to the software B (the PCD), software B encodes and transfers the data to the hardware, then responds back to software A ? Is my understanding correct ? You’re only talking about usermode components, but also mentionned IRPs, it is confusing.

If your problem is about how you’re going to design the way your application (soft. A) is going to wait for a reply from soft. B, we can’t deduce that for you unfortunately. As you said, the PCD is proprietary code, we don’t know how those requests have been implemented. Is it possible to open multiple sockets to the PCB ? If so, you could setup a queue and process everything in separate sockets (like each app that wants to communicate will have its own socket) ? You need a perfect understanding on how their GUI software works before going in.

The problem is that the PDC is currently a user-mode application, and we would like to keep that in user-mode as much as possible.

You can perfectly send requests over a socket from a kernel mode component to a usermode component. Don’t you need a kernel mode component anyway, to setup a virtual network adapter ?

After re-reading again… Is software A actually your kernel driver ?

For receive packet processing, how does the user mode component then indicate the data back to the network adapter?

Pipes ? Events ? Sockets ? I do not believe IRPs are designed for this.

Do you have source for these applications? If so, could you not change one of them to use a different port number, and write a very simple this-to-that that listens on port A and writes to port B? That’s about 10 lines of Python code.

Don’t you need a kernel mode component anyway, to setup a virtual network adapter ?
After re-reading again… Is software A actually your kernel driver ?

Yes, the VNIC would be the kernel mode component. This would be necessary to allow for:

  • multiple applications to use socket interface
  • bridging disparate network interfaces

So we have:
Software A = GUI
VNIC = new kernel component
Software B = PDC (user-mode)

The path I was envisioning was something along the lines of:

Software A  (GUI)   <->   VNIC   <->  Software B (PDC) <-> h/w

(That formatting may not be ideal, but hopefully it gets the picture across!)

You can perfectly send requests over a socket from a kernel mode component to a usermode component.

I had not thought of that! That seems like a much simpler approach than issuing & pending requests for buffer access.

Are you talking about using Winsock Kernel (WSK)??

seems like a much simpler approach than issuing & pending requests for buffer access

Really? I mean… that’s just ordinary Windows user-mode talks to a driver stuff, isn’t it??

Sending stuff to/from KM via Sockets? You COULD… but, isn’t that what ReadFile and WriteFile are for? I dunno… I probably shouldn’t get involved in this thread. I haven’t understood anything, including the first post. Your apps sends reads. Your driver puts those reads on a queue. When you have data, you use that data to satisfy the read. Heck, the students in my KMDF seminar do that by Thursday afternoon, never having written a Windows driver before. What am I missing?

Peter

1 Like

Correct, I am talking about the Winsock API.

See:

  1. https://docs.microsoft.com/en-us/windows-hardware/drivers/network/creating-sockets
  2. https://docs.microsoft.com/en-us/windows-hardware/drivers/network/sending-and-receiving-data

Thank you for that comment, Peter.

I think this thread became more complicated because - as you can see - fundamentally different suggestions have been offered, e.g. do not use inverted calls, but rather kernel sockets. Now after taking a look at that, I have to agree with you that maybe that is not a simpler approach after all.

I am probably over-thinking this. Serving up pending requests (i.e. inverted call model) does seem like the way to go; also, it should provide the most flexibility - which certainly is not a bad thing!

Agree?

But you are not able to modify the PDC code, do you ? From what I understood, that is specifically (aside from the 2 features you’ve mentionned) why you are doing all this (the constraints). You will have to open a socket to the PDC anyway ?

How are you going to communicate between your VNIC and the PDC ?

But you are not able to modify the PDC code, do you ?
For this iteration, I will not be modifying the PDC code, i.e. I need to maintain its socket interface and use it as a “block box”.

After posting my initial message to this thread, I came up with a scheme that I think will serve my needs. It involves adding a “shim” user-mode application that employs the inverted calls to exchange data with VNIC component. So now we would have:

Software A (GUI) <-socket-> VNIC <-pending I/O requests-> Software C (shim) <-socket-> Software B (PDC) <--> h/w

I think that allows me to develop iterations while preserving current interfaces.

Thoughts on this??

Sorry I was not clear earlier.

You’re overcomplicating the issue. You simply want to “proxy” the communication between Soft. A and Soft. B (PDC). Adding a third layer will simply add more requirements and deployments issues.

The inverted call model seems like a bad idea to me but it can be done. It’s a matter of preferences I guess. I agree that Winsock is complicated if you just happen to learn about it. Needs multiple calls and IRP/Stack creation just to setup a simple socket object…

The inverted call model seems like a bad idea to me but it can be done. It’s a matter of preferences I guess.
Unless I misunderstood, I think that that is the method that Peter V. was advocating above.

Eventually both Software A & B components will be modified. But for this iteration:

  • to demonstrate a VNIC for their use
  • while maintaining their current interfaces, and
  • not modifying them

I think what I presented is one approach to get me there.

I appreciate your feedback and suggestions here. Thank you!

This has GOT to be the world’s most confusing, over engineered, thread.

If the idea is to “glue” the output of Software A (which sends data via Sockets) to Software B (which receives data via sockets)… and for some reason they can’t talk directly to each other (hmmm… OK? They talk using different ports or something, I GUESS)… Then, write a user-mode sockets program that gets stuff from A and sends it to B, and your done.

Like I said… I should so stay out of this thread. I just don’t understand any of this.

ETA:

Gad! I’m not insane! I see that Mr. Roberts said exactly this, some days ago:

write a very simple this-to-that that listens on port A and writes to port B? That’s about 10 lines of Python code.

Peter

1 Like

Sorry - again - I was not clear. :frowning:

Software A & B do talk to each other, over a socket connection, that is true.

I tried to explain in my initial post to this thread that there is a requirement to insert a VNIC between them while leaving them “as is”.
That is the impetus for this thread: how to facilitate that communication.

a requirement to insert a VNIC between them

A “VNIC” that does WHAT, exactly? How do YOU define a VNIC?

How does the proverbial “10 line Python program” logically differ from your definition of a VNIC?

As we so very often say here: “What larger problem are you trying to solve?” Does A send socket traffic to B, which is on a different, pre-defined, IP Address? So, you want this VNIC to fake the IP address?? What is the problem that needs solving here?

Peter

1 Like

3rd attempt - who are my edits getting lost??

A “VNIC” that does WHAT, exactly? How do YOU define a VNIC?

VNIC = Virtual Network Adapter

As we so very often say here: “What larger problem are you trying to solve?” Does A send socket traffic to B, which is on a different, pre-defined, IP Address? So, you want this VNIC to fake the IP address?? What is the problem that needs solving here?

This is part of a larger government contract, so the less I say about “why” the better (if we can just leave it at that, it would be good…) :wink:

The requirement (from the powers that be) for the VNIC is to:

  • provide network interface for Software A
  • provide network interface for other future software applications
  • provide ability to bridge disparate network interfaces

It is important to note that the “lower edge” of the VNIC does not interface directly with h/w; it is the user-mode component PDC ( Software B ) that interfaces with h/w devices that go out to their “cloud”.

Also, for this iteration I wanted to keep Software A & B “as is”.

I hope this helps to clarify. Sorry for my earlier vagueness. I think in being careful to not divulge too much I just made things more confusing.

Presumably this is phase 1 in a larger project where you will make further changes? Possibly a new GUI control program is planned and this is some way of allowing both of them to talk to the controller simultaneously or interchangeably?

I have a comment that is pending approval, but yes, this is the first phase of a larger implementation. I want to prototype the approach such that I can leave Software A & B unmodified - for now - and support the requirement (as it is) is to introduce a virtual network component between those 2 user-mode applications. That is the crux of the problem.

to start, a network bridge. Presumably, with more functionality to come? but what kind? they already communicate via a network protocol, so it can’t be remoting the access. that’s why we are all confused i think

This is part of a larger government contract, so the less I say about “why” the better…

That’s convenient, but remember that a professional engineer has a responsibility to point out when a solution is going the wrong direction.

3rd attempt - who are my edits getting lost??

A “VNIC” that does WHAT, exactly? How do YOU define a VNIC?

VNIC = Virtual Network Adapter

As we so very often say here: “What larger problem are you trying to solve?” Does A send socket traffic to B, which is on a different, pre-defined, IP Address? So, you want this VNIC to fake the IP address?? What is the problem that needs solving here?

This is part of a larger government contract, so the less I say about “why” the better (if we can just leave it at that, it would be good…) :wink:

The requirement (from the powers that be) for the VNIC is to:

  • provide network interface for Software A
  • provide network interface for other future software applications
  • provide ability to bridge disparate network interfaces

**It is important to note that the “lower edge” of the VNIC does not interface directly with h/w; it is the user-mode component PDC ( Software B ) that interfaces with h/w devices that go out to their “cloud”.

Also, for this iteration I wanted to keep Software A & B “as is”.**

I hope this helps to clarify. Sorry for my earlier vagueness. I think in being careful to not divulge too much I just made things more confusing.