Thanks to all who responded.
The VAR is not motivated to pay me to change the architecture of their
client-server model to work around flaws in the initServerSocket() function.
The VAR has a solution today using the GCI which implements server
(listener) sockets in the C language. Ultimately they
I am trying to help a U2 VAR migrate their custom-developed socket interface
that uses the GCI to a pure BASIC solution using the U2 socket functions.
They realize that by doing this their customers will need to license
additional U2 seats, but they hate the UV GCI support issue on UNIX as UV
must
For anyone unfamiliar with the topic, see my short article What are
Sockets?:
http://nebula-rnd.com/articles/sockets.htm
That will also help to understand my response below.
Original text snipped to a minimum.
Gyle Iverson wrote:
Unfortunately, the initServerSocket() function has a few
flaws
I suspect she is writing a CLIENT socket service that RUNS on the server --
one where I'm opening a socket to get data from another service - and as any
process could be doing the same, I'd just want the next available socket,
please So I think the request is valid -- remember - our 3GL could
Hello, Tony.
Tony Gravagno opined...
Clients need to know the port of a server, so a server
absolutely requires a fixed and well-known port.
A server can have a randomly assigned port that is fixed and well-known only
between the client and the server. If the server only exists for the
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Gyle Iverson
Sent: Wednesday, December 14, 2005 7:43 PM
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] UniVerse server socket issues
Hello, Tony.
Tony Gravagno opined...
Clients need to know
DAVID WOLVERTON wrote:
I suspect she is writing a CLIENT socket service that
RUNS on the server -- one where I'm opening a socket to
get data from another service - and as any process could
be doing the same, I'd just want the next available
socket, please So I think the request is valid
