Will this stuff work between computers on a home network?

[barry]

I've never done any internet or network programming so it's totally new to me and I have no idea what might be done with it.  My thought is to write a simple small game that can be played across the internet and to test this between my new and old laptop, both connected to my home network.  But they both, externally at least, have the same IP.  Within my router, of course, they're different.

I guess my question is can I test it across the router and later use it across the internet without changing it?  I'm not asking how at this point, so much as I'm just wondering if this makes sense.  Not that I mind being told how but right now I'm just trying to get an idea what works and doesn't work to get a sense of what the possibilities are.

I won't do anything that'll make big demands.  It'll probably be something simple like some kind of word game; just something to use as a learning tool.

I have absolutely no context for this whatever.  I have some vague ideas about how networks work.  I read years ago about the various layers, etc.  But that's it.  All my communications programming was done in the days when RS232 and RS422 was king.

Thanks in advance for any pointers and ideas,
Barry

[Ionic Wind Support Team]

Barry,
Yes it will work like that, at least on my router I can ping any machine in my home network by its local 192.x.x.x IP address.  Which makes sense since each machine has to have its own IP address, which has nothing to do with the IP address provided by your ISP. 

Paul.

[barry]

Will the same code that works across my little network also work across the internet?  Can I give it a local IP to connect to a local computer and a remote IP to connect to a remote one?

I realize this is stuff that I can test but at the moment I'm just trying to get an understanding of what this thing is and I don't yet have the slightest idea how to test it.

Barry

[Barney]

Yes. Same code should work for LAN and WAN. I am writing a little game that is using client/server lib and it's working perfectly regardless of the LAN type I am using.

Barney

[Ionic Wind Support Team]

Barry,
Yes.  Your local machine IP address is always 127.0.0.1 on Windows systems.  I usually test servers on my local machine first before deployment, clients can connect to any IP address so you can specify 127.0.0.1 as a connection and have another connection to an external machine in the same program if you wish.

When you build a server and specify "" as the IP address (NCSOpenForClients) then it will listen on any IP addresses assigned to the machine it is run on. 

Paul.

[J B Wood (Zumwalt)]

This thing is working great for me as a server on my virtual host at GoDaddy and using my home machine as the clients.
No latency.
The packet size is freaken small.

[barry]

Thanks for the information.  Now I have to figure out what I want to do with it.  I guess I'll start with a little playful experimenting and see what it's all about.

Barry

[barry]

I just thought of something that would be useful to me if I can do it with this package.  I have a home network with 4 computers and sometimes i'd like to be able to run something on one computer from another; usually that means running something on my desktop from the laptop.

An example might be when I find some binary on a newsgroup that I'd like to download.  The client I use for this is on the desktop and I have to get the .nzb file and transfer it to the desktop and then walk over to the desktop and double click it.  The client recognizes .nzb files and will then download the file they represent.  This is usually some old time radio show.

I can just download it on the laptop but I only have one license for that client and I'd have to purchase another copy, which I can't afford.  There are other ways I can download it on the laptop but they're more involved.  In any case, if I could send the .nzb file to the desktop and execute it (which really means executing Newsbin.exe) that would be pretty nice.

However, that's just an example of what I'm talking about.  There are a lot of other things I'd like to do on the desktop from the laptop.

What I'm wondering is if making a client on desktop that I can connect to from the laptop and give it orders to execute any files with registered extensions would be a reasonable project for someone like me who knows practically nothing about network programming.

I've looked at the samples and I don't really understand what NSC_simple does.  It looks like the chat examples might have something in common with what I want to do except I'm not sure if I really need a server for this?  Do I?  Can two "clients" talk to each other?  Or could I turn the server into the program executor on the desktop?

Any thoughts on any of this?

Barry

[WayneA]

Hey Barry,

I have some limited experience writing network applications using various wrappers for winsock. I hope my experience and relative lack of experience will come together in a way that answers your question while also keeping my language pretty understandable.

Basically a client and a server are not all that different. At their heart, they both send and they both receive messages. Outside of that they are just like any other application you've ever written, it's just that at a certain point they get a message that is sent from another computer rather than just messages from windows saying button X was clicked.

I suggest you look at it this way, design your application without thinking about the networking component. Design your functions/subroutines in the exact same way you might if you had a GUI. You want to run specific files? Write a sub like this (pseudo code)

Code Select Expand

sub runfile(string path, string params)
system path,params
return
endsub

Now that you have this subroutine ready it can be called by any other portion of your program. You can now design an application around this subroutine that will run a file with parameters when a button is clicked, or when a message is received.

Once you have the core of your application designed, you can worry about the input interface. Generally, you would have a window/dialog that has several buttons, or a menu or maybe a console that allows commands to be typed in and you would process those in whatever way you choose. But instead you decide at this point that you want to run them from another computer. So we need to relay some information from one computer to another. Before any relaying of information is done both computers need to find each other otherwise they have no clue who to talk to. The TCP/IP protocol requires that we establish a connection first. This is where the client/server model comes into play. This is only important at the beginning of the connection. At this point it may be easier for you to think of this has a phone call. Someone needs to call you to tell you that they want you to run an application.

The server in this case is the guy waiting around the telephone. So he is "listening". Listening is what makes the server what it is. Otherwise its an application that isn't receiving messages. So You would run a function for listening and have a loop going that just waits for messages to come in. This is what defines the server and there is nothing else that is special about the server (at least nothing you need to worry about until you are more comfortable with sockets/networking apps programming in general).

The client is the girl that you gave your number too because she was waaaay to cute to ask for hers. She calls the lonely guy by the phone and says "I need you to do x and y on your computer." This would be described in your program by a 'connect' function. During the connection it is very standard to have a "handshake" where both applications send some information confirming what "protocol" they are using (like HTTP or FTP or whatever) - for simple applications you will be defining your own protocol and you can decide what information to send and I would keep this process pretty simple early on as you're learning.

After the client and server have connected and they are exchanging messages with each other (with send functions, and subroutines that receive and process the strings sent by the other applications that are connected) they are basically the same - the difference was only a big deal when connecting initially. Someone had to call the other, they can't both answer the phone and they can't both call the other. Either side can end the phonecall once they are done with the other one. There are graceful protocols to ensure they both are done, but again you can dictate how that is done and I'd keep iot prety simple as you get used to it. You'll get better at designing the communication system and determining the best way to send and receive requests, this is a pretty high-level look at what you'd be doing and the relationship between client/server. I hope it helped give you a stronger grasp. I promise you after some practice you'll get the hang of it really quick. The biggest mistake you can make is thinking that its a complicated process. It's soooo simple that most people try to make it more complicated than it is. Because communication between 2 or more PCs just HAS to be complicated, right? Nope!

[LarryMc]

Nice explanation

Larry

[barry]

The biggest mistake you can make is thinking that its a complicated process. It's soooo simple that most people try to make it more complicated than it is. Because communication between 2 or more PCs just HAS to be complicated, right? Nope!

Thanks.  As Larry says, it's a nice explanation.  I do have communications experience; 20 and 30 years ago writing terminal emulators and file transfer programs through serial ports.  I've probably wriitten a dozen or so of them, in all.  I've never written anything network related.  Also after retiring I went for over 10 years without writing a thing.  I've just begun dabbling with simple stuff in the past couple years.  I'm well beyond rusty.  I've rusted through.

I've read about some of the various concepts in networks; the various layers, etc.  That was years ago and I only read about them, I never really did anything with them to get a feel for any of it.  So I know a little of the theory in a patchy sort of way and that's about it.

Once I get the two programs talking to one another over the network I think the rest will be simple enough.  It's them talking to each other that's a mystery to me; at least without serial ports.

My preference would be to have a single program that can talk to a copy of itself on another computer.  If I was doing this through a serial port a single program would be the simplest way.  I'm not sure if that makes sense in a network.  Does it?  If it does are the server functions in that program separate from the client functions?

The mechanics of running a program aren't something I'm expecting problems with, although I haven't done that exactly in Windows.  I do have a program that runs explorer in directories on other computers but those are shared folders.  Probably this won't be much different.  I'll experiment with that first.

The GUI could be pretty simple.  A place to type commands and a place to display received results and a few buttons or, more likely, a drop down box to specify which computer to connect to.  A drop down would be better because it can be dynamic, or I can hard code names and use buttons.  This is for my own use.

Barry