Networking over LAN

[Zenerdiode]

I'm embarking on an application for work. There will be an industrial PC that aquires data from serial links and will be acting as a server. The clients will be connecting over the LAN/WAN. I've been looking at the libraries provided by Basic4PPC (including Agraham's NetUDP and Remoting) and I conclude I'll have to use TCP/IP as the data will be critical and I understand TCP will guarantee it's delivery or inform you otherwise.

My stumbling points so far are:

1. The Server needs to log the IP address of the Client; but there is no Property that will provide a list of connected clients. How is this handled inside the library? I would have thought the Server needs to know each one internally. I tried having the client send its IP on connection; but this is immediately open to abuse and if someone is connecting from home over VPN, it will just provide the IP of their router.
   
2. If the connection is broken by any means; server crashes, network lead drops out, client closes etc. the other party needs to know, so the client would get a message saying 'Server unavailable' and the Server would log the disconnection and release the client resources. If there are no events able to be raised for this, I'll have to write some handshaking code so each end knows the other is still there.
   
3. From the above; the Server once up and running will probably run for months, perhaps years at a time, so disconnected clients will have to be released so they don't build up. I've seen a response here - does that do what I require?

Many Thanks,

Christopher

 

[agraham]

This is a non-trivial project

but there is no Property that will provide a list of connected clients

It doesn't exist as the Network library Server object can only deal with one client at a time. You would need to manage multiple server objects and you would really need to do things asynchronously which the Network library doesn't support so you would need to run each Server on its' own thread or if it's on a PC a custom Network library implementing asynchronism is easy.

if someone is connecting from home over VPN, it will just provide the IP of their router.

That's all you will ever get outside their network. The local IP addresses inside the network are irrelevant and likely to change if the router doles them out by DHCP. You should be able to get the remote router IP address using the Door library to get the Server's Socket and then the Sockets' RemoteEndPoint and then the RemoteEndPoints' Address property.

If the connection is broken by any means; server crashes, network lead drops out, client closes etc. the other party needs to know

You should get exceptions thrown that will tell you.

I've seen a response here - does that do what I require?

Probably

 

[Zenerdiode]

This is a non-trivial project

Erm, Oh Dear... :sign0148:

or if it's on a PC a custom Network library implementing asynchronism is easy.

It is and that would be great, thank you. (No, that's just a joke as I could never be that arrogant or ignorant)

I stupidly thought because the Chit-Chat example handles multiple clients I may expand on that, but looking closer it creates a new Client object for each connection then polls them with a timer. It may still be of use to me.

I don't know the correct terminoligy but every computer on the network is assigned a 10.xxx.xxx.xxx IP address. Once connected via VPN, the VPN client connection is also assigned a 10.xxx.xxx.xxx IP from the the Domain DHCP server. So its just that IP address that I think may be obtainable from the Sockets' RemoteEndpoint and that will suffice. Thanks Andrew.

 

[lairdre]

Use something besides raw sockets

I have done some things like this in the past. There is no need to go as far as writing your application using sockets. Use the ftp client in the PDA and an FTP server on the host. It does not have to be FTP, just an idea.

FTP will work well you monitor your return codes, and track what is happening. It will also be secure because it is over the VPN connection.

You could spend your time coding the logic of the app and stay away from the transport.

I also noticed you mentioned VPN. I you PDA is actually on a vpn then the IP address of the devcie can be seen because you are actually tunneled in and will be using an IP address assigned by the VPN server.

Your app sounds fun, reuse code.

Ron

 

[Erel]

One Server object can actually work with many clients.
The Chit-Chat is a good example of working with many clients.
You will need to maintain the list of Clients objects and dispose them when they are no longer required.
Why is the ip of the client so important?

 

[agraham]

One Server object can actually work with many clients.?

Apologies, lax terminology on my part. One Server object can only handle a single connection at a time but hands it over to a new client. I was intending to highlight that at the server each connection needs to be managed individually - as Chit-Chat does - but wrongly associated that with multiple servers rather than the multiple individual clients handling each connection.

 

[Zenerdiode]

Why is the ip of the client so important?

When logging the connection has taken place - it will give me the 'where' because our 'LAN' is actually country-wide.

Normally form the client-side it wouldn't be a problem; I'd just use Client.GetIP() with its own hostname and send that to the Server. However its the occasional time when a Client connects to our LAN from home over a VPN connection. Using the same technique will just return the IP that their router has provided to them. From the Server side, it must know the socket of each connection and I presumed it would get an IP from that? You see, if I was to connect to the LAN over a VPN, the VPN client connection is allocated one of our 10.xxx.xxx.xxx IP addresses which would be good enough to prove where someone connected from. Phew, I'm trying to stop this going over my head too much.