Quote:I am trying to learn about Winsock, and I also need to devise away to use IPC. Im thinking two birds with one stone, and the interface might be alot easier (ie more unified) as far as IPC (local machine) / net applications (internet). What does anyone think?

Network is unreliable and slow. IPC is reliable and fast. This makes the nature of programming each completely different. IPC has no problems with synchronous calls, generally you'll want to use those in the first place. With sockets you need to work asynchronously, expect connection loss, latency and delays. While it may seem practical to abstract both, it's not really viable in practice.

Quote:oh yeah, Im looking for it as I go along in the SDK, but can winsock talk to other applications not utilizing winsock (case 1), or some sort of socket interface (case 2).

Winsock is an implementation of sockets, or TCP/IP networking. It is not a communication standard on its own. You cannot have TCP/IP networking without TCP/IP.

Quote:
I guess you can use named pipes for internet apps too, this stuff is really out of my scope.

I was also glancing at Remote Procedure Calls, but that stuff looks scary (MIDL).

It is completely possible to do IPC over TCP/IP. It is also possible to do TCP/IP over IPC or RPC. You could also do RPC to remotely access IPC on another machine that works over TCP/IP.

The real question is, why would you want to do it?

TCP/IP is portable and completely independant. Even completely different implementations can still communicate with each other.
IPC is just a mechanism, it's commonly used under Linux/Unix, less under Windows platforms. It does have portability issues, and is designed as inter-process (very important point) communication. It generally assumes same system libraries, same models, data structures, most commonly compiled from same base. While these are not requirements, it is not really robust by design.
RPC is yet another beast, which does not fit into either of the above. Once again, you face portability issues, but here standards have emerged (CORBA for example), which allow for completely portable solutions.

Before simply mashing everything together (yes, it's possible), ask yourself why do you need it, or what do you want to achieve.

A few years back I worked on a data processing middleware that used all of those and more.
- Data from devices was acquired in real-time using either generalized drivers or serial ports
- Communication between devices was done using one of the standardized TCP/IP protocols, for which the high-level implementation was already provided
- Various acquisition processes, configuration modules, data processing tasks and proxies communicated over shared memory structures via IPC
- For use in client applications, a CORBA interface provided access the shared memory structure

It was basically choosing each part for its merits and using it for a specific task, rather than simply mash everything together for the sake of it.

Quote:Original post by Antheus

Quote:I am trying to learn about Winsock, and I also need to devise away to use IPC. Im thinking two birds with one stone, and the interface might be alot easier (ie more unified) as far as IPC (local machine) / net applications (internet). What does anyone think?

Network is unreliable and slow. IPC is reliable and fast. This makes the nature of programming each completely different.

Yeah, but the OP implied that he wants to use it for IPC, ... I'm assuming he means two local processes on the same machine. If so, any traffic would use the loopback interface and would never hit the network. So would it really be that slow?