Socketting using VFP 1

[dkean4]

In 1999 I have been dabbling with Sockets and I had many problems keeping the connection working. Frequently the sockets would lock up and the app would have to be restarted. Has Socketting improved or stabilized with VFP 9?

I need to communicate between 2 PCs, the other PC being on the other side of the globe. The messages could be as little as a few words up to several paragraphs. The communication is not always going to involve Users on both ends, therefore I need VFP to be able to generate requests and replies from within an app, as well as forward and receive user messages. (Same app on both PCs) It would also be nice to be able to send images, short videos and audio. If not, possibly files could be passed back and forth via Shell Scripts by the VFP apps. No connection should be available for users to access the other PC, (for security reasons.)

If someone has a better idea than sockets, feel free to let me know.

Regards,



Dennis Kean

Simplicity is the extreme degree of sophistication.
Leonardo da Vinci

 

[Olaf Doschke]

First of all, for testing purposes only use one computer. On two computers you have to solve firewall problems. Use a por, that's open.

What do I mean with EXPAND frmSocket2. Well, expand the class, put your code for your data processing and response in the frxmSock2 class, fmrSock is just the main socket, this stays as is and does its job to listen for requests and spawn frmSock2 sockets to accept, process and respond to the requests. frmSock2 is the worker socket class.

Another reason for using a webserver and not roll your own. AS I said it already solves many problems you now have to solve yourself. Why still reject that? Even if I and Marco have different oppinions about what to use, we are both recommending using a webserver and http.

Bye, Olaf.

 

[Olaf Doschke]

Besides, I don't get what code you talk of. Did you use frmSock2 instead of frmSock? I never told you to avoid frmSock. This is good as it is, this has to be used as the main listener socket listening for incoming requests.

Bye, Olaf.

 

[dkean4]

Olaf,

I tried using it on a single PC on my first try. It locked up the Client side instance.

So, I tried it with 2 PCs and it did the same exact thing.


Well, if I use my hosting account I will have to encrypt the messages. The clients are spooked by passing the data via a Hosting account not owned by them.

So, maybe I should try to set up a server in my own shop. What about a VFP flavored server? Which one is the easiest to install? And is there one that does not require IIS. I detest IIS.

Dennis Kean

Simplicity is the extreme degree of sophistication.
Leonardo da Vinci

 

[Olaf Doschke]

>It locked up the client side
Have you tried the unmodified code first?

And once you stumble upon an error, why don't you refer back to the wiki article and read, whether someone else had the same problem?
Read.

I've encountered the clientobject to lock up when trying to access the server (clicking [connect]) in VFP 9.0 - add the FORCE command extension to the DOEVENT to get it to behave correctly again!

You sometimes ask question, which make me cringe. Is there a foxpro webserver that does not require IIS? The answer is not only in the question itself, it is in this thread. Read, please read.
As you want to run VFP code and not use IIS, you had three recommendations - well, three mentions of existing solutions I won't recommend - and didn't notice any one of them? They all use a Winsock, they all are not "commercial" webservers, but they are webservers. I would recommend using IIS, as it's the only webserver offering much more than http and is stable and mature and the AtiveVFP extension to that, as it allows VFP usage. I question your rejection of it.

I still would like to us nginx, but there first would need to be a module allowing calling into another process, even PHP execution only works via fastcgi, otherwise can only forward requests to other webservers, you could chain nginx with a foxpro webserver, that would allow usage of other nginx modules, though that's easier on Linux, as the Windows binary doesn't allow to configure modules dynamically.

Bye, Olaf.

 

[Nigel Gomm]

Dennis,

FWIW....

i've started with sockets a couple of times because they seemed like a good idea but always thought better of it after about an hour so.....

Things like error recovery, load sharing, multi-threading, availability always require we reinvent the wheel.

I sell a packaged product so have no knowledge of, nor control over, my customers' servers and infrastructure ; in that world a message queue on a cloud server would be my preferred solution - easier to code an outgoing connection from any desktop PC (or remote app) through firewalls etc. The more sensitive and ephemeral the data (e.g. readings from a sensor) the more likely i'd be to go this route and get the data secured asap.

If this was a custom solution or in-house development (and really needed a realtime response) i'd probably go for a RESTful API using west wind web connection (or other IIS based web server).

3rd favourite would be a USB drive by Taxi or DHL ( anything rather than sockets in VFP)


hth

n

 

[dkean4]

Olaf,

I tried it with and without the FORCE extension. But my VFP Beautify command put two commands on the same line and the code did not generate an error until down the road as you saw in my post. But I corrected it and it is working fine, now. Thanks, Olaf. (I will have to reinstall VFP from scratch sooner or later. I get a lot of these stupid little misbehaviors in VFP).

Anyway, Now, I am exactly where I was years ago. I can now communicate one way, from the client to the server, no problem. Do both PCs have to have the Server and Client apps running side by side, to talk back and forth? Or is it possible to use the WinSock object as Server and Client in the same class/object? The Methods in the aWinSock instantiation on both Client and Server are compatible.

Years back I had problems when I ran separate Client and Server VFP apps on both PCs, in a test with an associate in England. That is when the lockups and reboots took place. I think that the local client app was being discovered by the native Server app. Basically trying to talk to itself, I suspect. Which brings us to the point of how to determine an unused port preemptively, so I can hard wire it, other than to let the object run its default discovery and land on a mine, its own Server.

Or am I supposed to have a separate Client on my serving WinSock PC to communicate through the native WinSock Server with the other client?

I do not see anything obvious which leads me to either of these options.


By the way, the feature of frmSock acting as manager for the frmSock2 clients is astute. I did not think that far ahead, years back. Nice!



Dennis Kean

Simplicity is the extreme degree of sophistication.
Leonardo da Vinci

 

[Olaf Doschke]

>I can now communicate one way, from the client to the server, no problem. Do both PCs have to have the Server and Client apps running side by side, to talk back and forth?

This is not a one way communication. Take a look at the sample code, if you send GETTIME from the client, the server responds with the datetime. The whole purpose of a connect/request is to get a response.

IF UPPER( LEFT( This.cReceiveBuffer, 7 ) ) = 'GETTIME'
   This.SendData( TTOC(datetime()) + EOT )
ENDIF

And once again, using winswock directly I would only use for an easy way of communicating between peer clients in a LAN, any decent company wanting something to work via internet will have a Server which can also host an IIS and that'd be the backbone of such web communication. This type of request-response is not within http specs, it's not at all safe to act that simple, this will make it easy to flood a server with requests, for example. And also since you don't even see how this communication works, you are not fit to program from this as your base code. You don't see the wood for the trees.

If you want the server to be able to make requests to the client, too, that'll mean the client also has to have a listening socket, yes. Then both are client and server. But clients are typically clients making requests and servers accepting and responding to them (or rejecting them). The whole web works that way and you know how responsive that is, don't you?

Bye, Olaf.

Edit: Actually the wiki example is demonstrating to use a connection for more than just one request/response. You can send GETTIME as many times as you want, and if you would not only display the response time, but also expect something else to come back - a command for example, you have a duplex communication. In HTTP the connection is closed after the response is sent back and arrived. Here the connection stays open. This also may contribute to the instable nature of the Wiki socket implementation.

As an example of a server answering endless after one GETTIME request try this:

In the server prg add this class:

DEFINE CLASS timeTimer as Timer
   Interval = 1000
   cSocketname = ""
   
   PROCEDURE init()
      LPARAMETERS tcSocketname
      This.cSocketname = tcSocketname
   ENDPROC 
   PROCEDURE Timer()
       LOCAL lcSocketname
       lcSocketname = this.cSocketname
       Thisform.&lcSocketname..SendData( TTOC(datetime()) + EOT )
   Endproc
ENDDEFINE

In the DataArrival event of the server prg instead of [tt]This.Senddata( TTOC(datetime()) + EOT )[/tt] do this

IF !PEMSTATUS(thisform,"timer1",5)
          thisform.AddObject("timer1","timeTimer", This.name)
      Endif

Now just one GETTIME request sent from client to server cuases the server to send back time every second. The connetion stays up.

I would't use a socket this way, though, I would always prefer fresh connections for a single request/response, the close/release the socket object. The only long living socket will be a listener socket and it only manages the spawning of worker sockets and release of idle/state=7 worker sockets.

Bye, Olaf.

 

[Olaf Doschke]

Going a little back to what you said here:

WebRTC. Secondly, WebSockets might be less prickly than the VFP Sockets, though VFP Sockets is my number one choice

1. There is nothing like VFP sockets. There simply are sockets, sockets are a very low level port technology.
2. WebSockets is a name for a protocol using addresses starting ws:// or wss:// opposed to http:// https:// or ftp:// ftps:// as URLs.
3. WebRTC is yet another protocol.

All such web protocols are based on TCP/IP and use Sockets.

bye, Olaf.

 

[dkean4]

Yes, nigelgomm and Olaf, I hear you. It looks like HTTP is the better way to go.

Thank you for all your help.


Dennis Kean

Simplicity is the extreme degree of sophistication.
Leonardo da Vinci