Re: Socket Server Application Approach

Hi Jerry,

In case it's not clear... Sockets are THE way you do TCP/IP communications programming. Every program that does TCP/IP communications uses sockets (or calls something else that uses sockets.)

So your question shouldn't be "are sockets the right job for this?" Your question should really be "should I write my own, or use one that's provided by someone else?"

In the case of an https: server, I'd say your best approach is to use Apache. Have it call your RPG program as a CGI program. Since Apache and CGI are very widely used, you'll get a lot of functionality with minimal effort, and it's all be tested by thousands of programmers, and is solid code.

On the other hand, if you're doing this purely because you want to learn how it all works, how TCP/IP works, how SSL works, how HTTP works, etc, then it might be fun to write your own HTTP server. Personally, I wouldn't use any of the techniques in that outdated socket tutorial. I'd use either a spawn() API approach, or I'd use a "handoff server" approach depending on your performance/scalability needs.

I'd also consider whether it might be just as good to use inetd instead of rolling your own listener program.

There are so many things to know, sometimes it makes my head explode. (Fortunately, my head got better.)


GKern@xxxxxxxxxxxxxxxx wrote:

I've finally made it to the end of Scott Klement's Socket tutorial (well not quite, there's the UDP stuff at the very end).
I have a request to develop the back end code that will accept patient payments over the internet. The web application is written in ASP.net and it will connect (using https) to an ILE RPG socket server. The web application will be sending a pipe delimited string of data.

Since the web application could accept multiple payment requests simultaneously, I have a few questions:

Would a socket spawning approach be a good fit for this application? After (re)reading the tutorial I came to the conclusion that it would be, based on the comment that should one job crash other jobs wouldn't be affected (as could be the case using the select() approach).

And since this application would be accepting input over the internet via server instances, I'm wondering if the RdLine/WrLine (as shown in the tutorial) is acceptable (as opposed to using GetLine & PutLine) from the select() approach? Does it matter? I'm concerned that with either approach I may still need to be concerned that the entire string of data (probably not more than 2048 bytes) may not be received with one read - which leads to my next question:

Should the RdLine/GetLine occur in a loop to ensure the full contents of the string are received? Or does specifying the (maximum) length of RdLine always return (up to) that number of bytes?

And finally, since the example SVREX7I does not use a "dow 1=1", I'm coding my logic as follows:

1) Website connects to server instance, and passes data string to server instance;
2) Server instance reads data via RdLine, does edits and returns result string to website via WrLine;
3) Server instance ends.

At this point should the server instance job be allowed to end?

If for example, the results returned to the website indicate that the data string was incomplete or contained errors, should a subsequent retry (by the user) occur and interact with the server instance that did the initial edit?

Or should I allow a new server instance to take control?

My guess is that I would want a new server instance each time since I have no guarantee that the user on the internet will, with certainty, continue the transaction to completion.

This is the direction I'm moving in. Comments welcome.

Thanks!

Regards, Jerry

Gerald Kern - MIS Project Leader
Lotus Notes/Domino Administrator
IBM Certified RPG IV Developer
The Toledo Clinic, Inc.
4235 Secor Road
Toledo, OH 43623-4299
Phone 419-479-5535
gkern@xxxxxxxxxxxxxxxx


This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please inform the sender by reply e-mail and destroy this and all copies of this message.