Web Development with Visual FoxPro
Multi-server, multi-protocol application advice
Gravatar is a globally recognized avatar based on your email address. Multi-server, multi-protocol application advice
  n/a
  All
  Apr 15, 2014 @ 05:00am
This may seem unnecessarily complicated, but I thought I'd throw it out and see if anyone had any suggestions.

The application that I'm working on has many sites, with anywhere from 5 to 200 users at each site. The site databases are all local. I would like to provide some basic reporting and answers to common user requests by creating a centralized public web server. This server would have two connection interfaces, TCP and HTTP. There would also be a local server at each site, using the same two protocols, but without a publicly accessible IP address.

When the local site server starts, it would establish a TCP connection to the public server, sending its Site ID and Local IP address. The connection would stay active indefinitely and would handle reconnecting in the event of a disconnect. The public server, upon accepting the connection would register the site and store its local IP for reference later.

Use case:
A user makes an HTTP request from the public server (including their site ID). The public server, having no stored data of its own to service the request, can do one of two things.

1) Try to redirect the user’s request to their local site server (Ideal, but only works if the user is on the local network)
-or-
2) Make a TCP request to the local site server on behalf of the user, receiving back an HTML response string (via TCP), and then finally delivering that response via HTTP to the user.

So the question is - is there any way, via Javascript or maybe even built into WebConnect, to tell whether or not the user is making the request from within their LAN? If so, then what would be a reasonable method of redirecting them to their local site server?

Thanks for any advice,
-Matt

Gravatar is a globally recognized avatar based on your email address. Re: Multi-server, multi-protocol application advice
  Rick Strahl
  Matt W
  Apr 15, 2014 @ 07:08am

Why in the world would you want to support TCP/IP as raw protocol in this day and age where every platform has an HTTP client?

+++ Rick ---



This may seem unnecessarily complicated, but I thought I'd throw it out and see if anyone had any suggestions.

The application that I'm working on has many sites, with anywhere from 5 to 200 users at each site. The site databases are all local. I would like to provide some basic reporting and answers to common user requests by creating a centralized public web server. This server would have two connection interfaces, TCP and HTTP. There would also be a local server at each site, using the same two protocols, but without a publicly accessible IP address.

When the local site server starts, it would establish a TCP connection to the public server, sending its Site ID and Local IP address. The connection would stay active indefinitely and would handle reconnecting in the event of a disconnect. The public server, upon accepting the connection would register the site and store its local IP for reference later.

Use case:
A user makes an HTTP request from the public server (including their site ID). The public server, having no stored data of its own to service the request, can do one of two things.

1) Try to redirect the user’s request to their local site server (Ideal, but only works if the user is on the local network)
-or-
2) Make a TCP request to the local site server on behalf of the user, receiving back an HTML response string (via TCP), and then finally delivering that response via HTTP to the user.

So the question is - is there any way, via Javascript or maybe even built into WebConnect, to tell whether or not the user is making the request from within their LAN? If so, then what would be a reasonable method of redirecting them to their local site server?

Thanks for any advice,
-Matt



Rick Strahl
West Wind Technologies

Making waves on the Web
from Maui

Gravatar is a globally recognized avatar based on your email address. Re: Multi-server, multi-protocol application advice
  n/a
  Rick Strahl
  Apr 15, 2014 @ 08:07am
Familiarity mostly. I've had my socket servers running for years and made many tweaks along the way. They work well and they're fast. The thing is, I can't see a way that this scenario would work without some kind of connected protocol... If the user connects to the public server and requests a web page, how could the public server contact the local site server if there wasn't some kind of live connection? (I'm envisioning the local site server most likely being firewalled to the outside world.) I'm all in for an easier way though!

Why in the world would you want to support TCP/IP as raw protocol in this day and age where every platform has an HTTP client?

+++ Rick ---



This may seem unnecessarily complicated, but I thought I'd throw it out and see if anyone had any suggestions.

The application that I'm working on has many sites, with anywhere from 5 to 200 users at each site. The site databases are all local. I would like to provide some basic reporting and answers to common user requests by creating a centralized public web server. This server would have two connection interfaces, TCP and HTTP. There would also be a local server at each site, using the same two protocols, but without a publicly accessible IP address.

When the local site server starts, it would establish a TCP connection to the public server, sending its Site ID and Local IP address. The connection would stay active indefinitely and would handle reconnecting in the event of a disconnect. The public server, upon accepting the connection would register the site and store its local IP for reference later.

Use case:
A user makes an HTTP request from the public server (including their site ID). The public server, having no stored data of its own to service the request, can do one of two things.

1) Try to redirect the user’s request to their local site server (Ideal, but only works if the user is on the local network)
-or-
2) Make a TCP request to the local site server on behalf of the user, receiving back an HTML response string (via TCP), and then finally delivering that response via HTTP to the user.

So the question is - is there any way, via Javascript or maybe even built into WebConnect, to tell whether or not the user is making the request from within their LAN? If so, then what would be a reasonable method of redirecting them to their local site server?

Thanks for any advice,
-Matt



Gravatar is a globally recognized avatar based on your email address. Re: Multi-server, multi-protocol application advice
  Rick Strahl
  Matt W
  Apr 15, 2014 @ 08:53am
WebSockets is one way, although that's a problem with VFP because of the high overhead and not multi-threaded nature of VFP.
Typically you use NodeJs, or like SignalR on .NET to do this sort of thing. All way easier than sockets.

If you're doing TCP/IP today with sockets, then WebSockets should work similar. Most Web Servers support the protocol - i haven't looked into how the pass off to application code happens though but I'm sure you can find out. It's bound to be easier than TCPIP and leaves you with single infrastructure.

+++ Rick ---



Familiarity mostly. I've had my socket servers running for years and made many tweaks along the way. They work well and they're fast. The thing is, I can't see a way that this scenario would work without some kind of connected protocol... If the user connects to the public server and requests a web page, how could the public server contact the local site server if there wasn't some kind of live connection? (I'm envisioning the local site server most likely being firewalled to the outside world.) I'm all in for an easier way though!

Why in the world would you want to support TCP/IP as raw protocol in this day and age where every platform has an HTTP client?

+++ Rick ---



This may seem unnecessarily complicated, but I thought I'd throw it out and see if anyone had any suggestions.

The application that I'm working on has many sites, with anywhere from 5 to 200 users at each site. The site databases are all local. I would like to provide some basic reporting and answers to common user requests by creating a centralized public web server. This server would have two connection interfaces, TCP and HTTP. There would also be a local server at each site, using the same two protocols, but without a publicly accessible IP address.

When the local site server starts, it would establish a TCP connection to the public server, sending its Site ID and Local IP address. The connection would stay active indefinitely and would handle reconnecting in the event of a disconnect. The public server, upon accepting the connection would register the site and store its local IP for reference later.

Use case:
A user makes an HTTP request from the public server (including their site ID). The public server, having no stored data of its own to service the request, can do one of two things.

1) Try to redirect the user’s request to their local site server (Ideal, but only works if the user is on the local network)
-or-
2) Make a TCP request to the local site server on behalf of the user, receiving back an HTML response string (via TCP), and then finally delivering that response via HTTP to the user.

So the question is - is there any way, via Javascript or maybe even built into WebConnect, to tell whether or not the user is making the request from within their LAN? If so, then what would be a reasonable method of redirecting them to their local site server?

Thanks for any advice,
-Matt






Rick Strahl
West Wind Technologies

Making waves on the Web
from Maui

Gravatar is a globally recognized avatar based on your email address. Re: Multi-server, multi-protocol application advice
  n/a
  Rick Strahl
  Apr 15, 2014 @ 10:08am
Single infrastructure would be nice. I read up a bit on both technologies. WebSockets does feel a little more familiar, but both will have a learning curve. Taking browser compatibility into consideration, which would you choose?


WebSockets is one way, although that's a problem with VFP because of the high overhead and not multi-threaded nature of VFP.
Typically you use NodeJs, or like SignalR on .NET to do this sort of thing. All way easier than sockets.

If you're doing TCP/IP today with sockets, then WebSockets should work similar. Most Web Servers support the protocol - i haven't looked into how the pass off to application code happens though but I'm sure you can find out. It's bound to be easier than TCPIP and leaves you with single infrastructure.

+++ Rick ---



Familiarity mostly. I've had my socket servers running for years and made many tweaks along the way. They work well and they're fast. The thing is, I can't see a way that this scenario would work without some kind of connected protocol... If the user connects to the public server and requests a web page, how could the public server contact the local site server if there wasn't some kind of live connection? (I'm envisioning the local site server most likely being firewalled to the outside world.) I'm all in for an easier way though!

Why in the world would you want to support TCP/IP as raw protocol in this day and age where every platform has an HTTP client?

+++ Rick ---



This may seem unnecessarily complicated, but I thought I'd throw it out and see if anyone had any suggestions.

The application that I'm working on has many sites, with anywhere from 5 to 200 users at each site. The site databases are all local. I would like to provide some basic reporting and answers to common user requests by creating a centralized public web server. This server would have two connection interfaces, TCP and HTTP. There would also be a local server at each site, using the same two protocols, but without a publicly accessible IP address.

When the local site server starts, it would establish a TCP connection to the public server, sending its Site ID and Local IP address. The connection would stay active indefinitely and would handle reconnecting in the event of a disconnect. The public server, upon accepting the connection would register the site and store its local IP for reference later.

Use case:
A user makes an HTTP request from the public server (including their site ID). The public server, having no stored data of its own to service the request, can do one of two things.

1) Try to redirect the user’s request to their local site server (Ideal, but only works if the user is on the local network)
-or-
2) Make a TCP request to the local site server on behalf of the user, receiving back an HTML response string (via TCP), and then finally delivering that response via HTTP to the user.

So the question is - is there any way, via Javascript or maybe even built into WebConnect, to tell whether or not the user is making the request from within their LAN? If so, then what would be a reasonable method of redirecting them to their local site server?

Thanks for any advice,
-Matt






© 1996-2024