Sockets

[Brian K. White]

On 5/16/2012 1:04 PM, Ed Hilovsky wrote:
> Since I still haven't received any documentation regarding the socket
> license I purchased, I would like to get confirmation on the following:
>
>
>
> A rclerk process  starts another rclerk in a different file that will open /
> send/ receive / close the socket. Once this second rclerk exits back to the
> original process will the socket license be released and available for use
> by a completely different user / process ?

Also note, if you are willing to do that, run a system() command to 
perform the transaction, then possibly you don't need to even use fp 
sockets at all, just make a script that uses wget or curl, or, a trick 
I've used a few times on *nix is use the user() command with netcat or 
socat or the like.

The user() method is very tricky but it can be done and it gives you 
almost socket-like ability, in that you can open a connection and talk 
back and forth on it all from within processing so you can access all 
the filepro data and perform programming logic etc, then close the 
connection. The trickiness comes from the fact that you have to be very 
sure at all times in your processing that you know what the server will 
be saying or expecting you to say, and keep your own side of the 
conversation always in sync with that. If you get out of sync because 
the server did something you didn't expect, and you're talking while 
it's no listening or it's trying to say something and you're not 
listening, your process may just hang forever blocking on either output 
or input.

So basically, for well defined protocols and/or at least well behaved 
servers with consistent behavior, it's no problem, but for ill-defined 
proprietary things and inconsistent server behavior, it can be a problem 
until you've learned all the servers quirks the hard way.

user() is only available on the unix/linux/bsd versions of fp, not 
windows, but it's been available for a long time. At least as far back 
as 4.8.

Way to go fp. Is anyone actually using their sockets feature?

I do a fair amount of network traffic from within processing and I do it 
all with system and wget or curl (and often a cgi that runs fp on the 
other end if I'm doing fp to fp) or user and netcat or socat, possibly 
with a script wrapped around netcat/socat instead of using it directly.

Whatever their logic for pricing and licensing that way, I don't think 
it worked, assuming the goal was to make money by selling licenses for 
either sockets features or base fp upgrades to even gain the privilege 
of then buying the sockets feature on top. The techniques I use have 
been available as long as system() and user() have, and suffer from no 
arbitrary artificially injected surprise run-time breakage due to some 
license counter.

Why in the world would anyone start using something so full of pitfalls 
and land mines? Efficiency from not having to fork child processes? 
Whatever the increased efficiency from not forking a system or user 
process, I can't imagine it compares to the nonsense exhibited in this 
thread.

Even if he was clearly told the way the counter would work, and 
understood it, and was ok with just buying whatever number of licenses 
required, it's still a stupid waste of everyones time just even having 
to deal with it and remember it during upgrades and migrations etc.

I don't even know what these licenses cost, and it doesn't matter. The 
biggest problem isn't even with the cost of the license themselves. Even 
if they were $1 each I would have a hard time buying into the 
arrangement just because I try to avoid knowingly shooting myself in the 
foot if it's in any way avoidable. Even if the licenses are so cheap you 
can just buy 1000 of them whether you need them or not, that's still:

* An artificial limit I may run into some day. Even if I buy enough 
licenses to max out the operating system's capability, that changes too. 
Some day a 64bit version of linux using ipv6 or some other stack 
entirely will exceed the current standard limits. The fp routines won't 
know about those anyways and so could never exceed the original limits, 
but that actually just makes the point even more, because without the 
source to fp, those routines cant be counted on to adapt to those new 
times when they come. But I can swap out the curl/netcat command used in 
user/system commands with completely different things that may not even 
use tcp/ip any time I want effortlessly forever, as long as the clerk 
binary is still runnable at all.

* An artificial technical puzzle piece that absolutely will break every 
once in a while. The license counter itself does, and always will, 
occasionally break. Like anything else. The key differences are, it's an 
_extra_ component that doesn't actually help do any functional 
productive job, it's just there to intentionally break things under 
certain conditions, so not using it at all reduces the points of failure 
in the system, increasing overall quality, and everything else can be 
debugged and fixed or replaced or worked around by myself or any 
programmer or sysadmin, so it's less of an issue that say, maybe curl 
will break sometimes too.

* An artificial admin/maintenance chore to add to the list that must be 
addressed on every individual physical server. 
Buying/installing/activating the licenses, and maintaining a record of 
them along with the other fp licenses forever so you don't lose your 
investment when the server dies, etc...

Price'm however you want because long before I even care what the price 
is, I already am not even looking at them as a potential solution to any 
problems in the first place. The days of putting up with that kind of 
nonsense were over way back in 1995 or so.

-- 
bkw