Thread: RPC instead of Winsock

So apparently the teacher doesn't like winsock, says we must use RPC to do network communication on a Windows machine... seems that doing RPC-XML on Linux is easy enough, but I'm finding it nearly impossible to find RPC libraries that aren't 40 miles long...

Mind you, this is a beginners C programming class...

He was also earlier claiming that RPC allows you to do communication without ports... Seems impossible being as TCP/IP packets are constructed with port data...

Looking for a way to send and receive simple bits of text, had it working fine on Winsock, but says that because he used RPC "some time ago, but forgot how to do it" that we can do it.



Of course, I can't tell why he expects us to use RPC, it seems counter-productive to the problem, and it's something he can't even confirm exists for Windows.

Is is just me or do people totally forget to actually ask a question these days?

One could mistakenly assume that you simply came here to moan.

I think he means using RPC instead of manually using Winsock since any Windows RPC facility is most likely built off of Winsock.

RPC isn't as bad as you might think, though.

Originally Posted by MacGyver

RPC isn't as bad as you might think, though.

Thats what I thought too, however finding RPC for Windows seems to be difficult, there is SOAP that we're looking into, but I don't really get how thats much different from Winsock, then again we haven't gotten far into it, and as I understand it, constructing winsock to take arguments to determine which functions to call is basically RPC, correct?

Originally Posted by MacGyver

I think he means using RPC instead of manually using Winsock since any Windows RPC facility is most likely built off of Winsock.

He was wanting us to throw out the Winsock code I got working and "use RPC instead of Winsock". Really confused being as I understood it, RPC is a programming method, not a replacement for network communication. We ended up blowing an entire day of class (5 hours, one day a week) looking up libraries for RPC, until I explained that I couldn't find an implementation that didn't involve Winsock in a more complicated fashion (usually used for application distribution, or some way-over what we need thing), and that we weren't going to find strictly RPC network communication libraries. That it's a method of communication, not a communication structure.

His direct words were "you don't need ports" and "you don't need winsock, there are easier ways". I have yet to find either.


Is going the way of SOAP better? Or should I construct some overlay on Winsock so it acts with an RPC like behavior? By the end of class he seemed to accept the idea of writing an overlay for Winsock being as none of us were finding anything.

Didn't he give any examples or mention anything?

Try reading up on MSDN: http://msdn2.microsoft.com/en-us/library/aa373570.aspx

Originally Posted by MacGyver

Didn't he give any examples or mention anything?

Try reading up on MSDN: http://msdn2.microsoft.com/en-us/library/aa373570.aspx

No, thats what really kind of bugs me, he's giving us vague references to things he's claimed to do, that frankly my last computer classes have said are impossible without writing your own drivers for the operating system and constructing your own packet system (oh and re-writing switches and routers), and that he can't recall any specifics, but that it was somehow easier.

The fact that our class has 150 combined hours and have come up with nothing that he describes and wanted us to use until we told him there was simply nothing like what he's telling us about, and that I was guessing our best bet was to use Winsock to write our own RPC system.

His exact words contained these key phrases:
"What if I block all ports? With Winsock you have to use ports, with RPC I didn't."
"It is much simpler than this (talking about my possibly 3-4 pages of winsock code)"
But when we ask how, or what libraries, or if he could remember any slightest detail that may help us track it down, he would shrug and say it was our job to research it. It's one thing for us to learn, it's another to give us some imaginary idea to chase after for two critical class periods.

Originally Posted by Codeplug

There's RPC the protocol and there's RPC the concept.

There are a couple of RPC protocols defined. None of them are tied to any particular transport, but TCP is a common transports which is used. On Windows, that means Winsock is used. Using the Windows RPC library seems *way* out of scope for a "beginners C programming class".

>> Is going the way of SOAP better?
Not for a beginners C programming project on Windows.

>> he seemed to accept the idea of writing an overlay for Winsock
Since you've already written code to send messages you're just about finished. Send a text message containing a function to call and it's parameters. The reply text message would contain the return value. Nothing fancy, but it's RPC (the concept).

gg

Yeah, a few students haven't even touched a language before this class, thats how new some of us are.

Basically as I understand it, Winsock can only transfer character values, so we're serializing a struct that contains function and parameter data, and passing that as a character string. It would be nice to be able to just send the byte data of the struct to be honest, but I dunno if thats possible.

Originally Posted by StrangeWill

"What if I block all ports? With Winsock you have to use ports, with RPC I didn't."

I nominate this quote for some sort of award.

Oh, yeah.... Get a refund for this course.

Originally Posted by Codeplug

He may be confusing RPC with IPC. You can have Inter-Process Communication without "using ports". But any type of IPC that doesn't "use ports" implies that the two processes which are communicating are on the same box.

gg

Or at the very least that you don't use "Internet Protocol" for the communication - if you use for example a plain serial port to send/receive commands, you don't use ports in the internelt protocol sense [you are of course using a serial port, but that's a physical connection, not an IP port].

--
Mats