communicates functions?

[tommyt11]

I'll be as detailed as possible. Looking for direction not solution. I am a GUI guy. I write the client side of a service. Developer writes a server side (php) based program. Plan is to have a compiled program ( not a dll ) in place on client that communicates functions to and fro from client interface (myVBProject) to server and back. The compiled middle piece is another project. My quandary is looking through all possible resources I can't figure what VB net calls this process. Am I linking to an outside file , am I including an outside file, am I merely calling a COM between the two. Just point me in the right direction. I'll do the studying. Just need direction.

 

[jmcilhinney]

You're talking about two separate applications so you're talking about IPC, i.e. inter-process communication. I'd be thing thinking to use UDP or TCP, so you would probably be looking at types in the System.Net.Sockets namespace.

 

[tommyt11]

Maybe I need to clarify. The center or middle module is merely a compiled group of functions. Does that makes sense. My client program wants to pass strings or objects to center module which in turn passes up to server gets a return and sends back to my client program. Is this even feasible.

 

[jmcilhinney]

The center or middle module is merely a compiled group of functions. Does that makes sense.

No it doesn't. You specifically stated:

Plan is to have a compiled program ( not a dll )

If it's not a DLL then it's an EXE, i.e. a separate program. If you don't want a separate program then it IS a DLL. What language is this middle layer supposed to be written in? Syaing that it is "merely a compiled group of functions" makes it sound like unmanaged C/C++, but that's still going to be a DLL.

 

[tommyt11]

Apologize jim, I am fairly new to complex programming. So I may seem ignorant. All previous have been standalone. So to clarify, the middle piece if we do not want it a dll must be an exe. got it. Do I still then run on your first action as an IPC type structure and learn from there. Any references would be great. Thanks for putting up with my lack of knowledge.

 

[jmcilhinney]

So to clarify, the middle piece if we do not want it a dll must be an exe. got it.

I think that it's probably important to ask at this point, why don't you want it to be a DLL? Just not wanting it to be a DLL is not really justified. You should clarify your requirements and then see what best meets those, be that creating a DLL or something else. If you want it to be a separate program then that basically means an EXE.

 

[tommyt11]

Developer has concerns that a dll is too readily hacked whereby they could compromise our interim process and break security. Is that justified in his thinking. Initial plan was a dll which would have saved me all this trouble. But his thinking was thus. They could replace our dll with their own and bypass security measures we were building in place.

 

[jmcilhinney]

Developer has concerns that a dll is too readily hacked whereby they could compromise our interim process and break security. Is that justified in his thinking. Initial plan was a dll which would have saved me all this trouble. But his thinking was thus. They could replace our dll with their own and bypass security measures we were building in place.

If they could replace the DLL then they could just as easily replace an EXE. If you want to verify the identity of an assembly then you use digital signatures.

 

[tommyt11]

That's kind of what I figured you would end up saying. I'll let him know and we can proceed without questions. Appreciate your advice and tutelage.jim