🚀 go-pugleaf

"Daniel Stevenson" <daniel@ocreage.com.au> wrote in message
news:429bfb58@newsgroups.borland.com...

> it is this observation that makes me think that there is a problem
> with permissions which is causing my socket connection to not
> work.

Sockets are not subject to most security permissions, that is what makes
them very ideal for use in services.  I use TCP sockets in many of my own
services and they have always worked fine regardless of the user account
(albeit the account used for the service does need network rights in order
to reach resources that are external to the machine).


Gambit

> > it is this observation that makes me think that there is a problem
> > with permissions which is causing my socket connection to not
> > work.
>
> Sockets are not subject to most security permissions, that is what makes
> them very ideal for use in services.  I use TCP sockets in many of my own
> services and they have always worked fine regardless of the user account
> (albeit the account used for the service does need network rights in order
> to reach resources that are external to the machine).

This was my thinking as well which was why I chose TCPSockets, but I can't
think of why it is causing this problem.

I have done some more testing and I'm finding the following:

Service: Socket activates
App: Attempts to activate client socket
App: Receives socket error 1110 ("Unknown socket error")

When the service is installed under the same user account this all connects.
I know this is not very helpful but I'm stumped as to what could be causing
this problem.

> Where did you get 1110 from?  Socket errors are always 5 digits.  That
looks
> more like a Win32 API error code (1110 = ERROR_MEDIA_CHANGED)

Good observation, the code I have been using is...

void __fastcall TMyfrm::ClientSocketError(TObject *Sender,
      TCustomWinSocket *Socket, TErrorEvent ErrorEvent, int &ErrorCode)
{
  AnsiString ErrorString = GetSockError(ErrorCode);
  StatusBar->Panels->Items[1]->Text = ErrorString;
  ErrorCode = 0;   //stop exception from being thrown
}

//ClientSocket is a TClientSocket component

AnsiString __fastcall TMyfrm::GetSockError(int code)
{
  switch (code)
  {
    case 10004: return "A blocking operation was interrupted by a call to
WSACancelBlockingCall.";
    case 10009: return "The file handle supplied is not valid.";
    //case values 1010 to 11028 removed due to space
    case 11029: return "An invalid shape discard mode object was found in
the QOS provider specific buffer.";
    case 11030: return "An invalid shaping rate object was found in the QOS
provider-specific buffer.";
    case 11031: return "A reserved policy element was found in the QOS
provider-specific buffer.";
    default :
      return "!! Unknown Socket Error " + AnsiString(code);
  }
}

The exact text of the return value from the call to GetSockError is "!!
Unknown Socket Error 1110" which indicates the socket is returning a 4 digit
value.

It looks as though I have 'fixed' it, I'm not sure that 'fix' is the right
word because what I did should not have made a difference to the problem we
have been exploring, let me try to explain...

Previous to opening the socket connection within the Application I perform
the following:

1 - I retrieve settings from an INI file; if not present than I use default
settings (both settings are the same so not having the INI shouldn't have
made a difference); I initially didn't use a INI file and relied upon the
default values.

2 - I checked whether the service was present in the SCManager using
OpenSCManager() and OpenService(); this was found to be present

3 - I then started the service using OpenSCManager() and  OpenService() and
ControlService() to interrogate the state of the service, if the service is
running I than am able to attempt to open Socket connection; service was
found to be running.

4 - I then attempt to open the socket connection; which previously was
causing error 1110???

My fix was to have installshield create the INI file during installation.
Although steps 1 to 3 were returning valid results, it failed for some
reason when using defaulted values (ini not present) and worked when using
an pre-existing INI file even though the values seen through debugging were
identical.

And to really confuse the issue, it worked when I manually installed the
service AND still didn't have pre-existing INI file (therefore was
sucessfull when using the default values)


I think I must have been doing something wrong, but even though it is
working and I know how to make it work, I still can't figure out why it
worked, and now I think I have 'blinking cursor fever' from looking at this
screen too long and am officially giving up in attempting to understand this
any further.

Thanks for your help.

"Daniel Stevenson" <daniel@ocreage.com.au> wrote in message
news:429d4a14@newsgroups.borland.com...

> 4 - I then attempt to open the socket connection; which
> previously was causing error 1110???

There is no socket error 1110.  As I said, socket errors are always at least
5 digits, beginning at 10004.  Are you absolutely sure that you are reading
it properly?  There is, however, a socket error 11001 (WSAHOST_NOT_FOUND).


Gambit

> There is no socket error 1110.  As I said, socket errors are always at
least
> 5 digits, beginning at 10004.  Are you absolutely sure that you are
reading
> it properly?  There is, however, a socket error 11001 (WSAHOST_NOT_FOUND).

I'm absolutely sure, I posted the code that was returning the error code on
a previous message, the error code was definately coming from the
TClientSocket's OnError event.  The only thing I can think of is if the
socket error event is somehow using GetLastError internally and was finding
another error code.

I wish i could send you my code so that I could show you, but I can't, I had
even performed a screen capture to attach to this message but I can't seem
to include attachments to these posts to show you either.  :(

Since working out its the missing INI file causing the problem, I was able
to reproduce the error on my development environment, and it was caused by
me assigning NULL to both Host and Address and only assigning a Port to the
TClientSocket before opening the socket.

Maybe 1110 is "insufficient parameters"?

"Remy Lebeau (TeamB)" <no.spam@no.spam.com> wrote in message
news:429deb7c$1@newsgroups.borland.com...

> There is no socket error 1110.

I just checked the source code for TClientSocket.  There is a hard-coded
1110 error code when TCustomWinSocket::AsyncInitSocket() fails.  You never
said what the ErrorEvent parameter of OnError was assigned to, but 1110 is
sent when ErrorEvent is eeLookup.  The only condition that causes this error
is when the Host and Address properties of TClientSocket are both empty.


Gambit

"Daniel Stevenson" <daniel@ocreage.com.au> wrote in message
news:429e4802@newsgroups.borland.com...

> I was able to reproduce the error on my development environment,
> and it was caused by me assigning NULL to both Host and Address
> and only assigning a Port to the TClientSocket before opening the socket.

Yes, that would do it.  You cannot leave both the Host and Address
properties empty, or else TClientSocket has no way of knowing where it is
supposed to connect to.


Gambit

Sorry for wasting your time, at the end of the day it proved to be my poor
programming techniques and even poorer debugging skills - I got too caught
up with trying to debug and find the problem on the installed machine rather
than on the development environment.

> I just checked the source code for TClientSocket.  There is a hard-coded
> 1110 error code when TCustomWinSocket::AsyncInitSocket() fails.  You never
> said what the ErrorEvent parameter of OnError was assigned to, but 1110 is
> sent when ErrorEvent is eeLookup.  The only condition that causes this
error
> is when the Host and Address properties of TClientSocket are both empty.

And thanks for your help, if you weren't so adament that there shouldn't be
an error message 1110 I wouldn't have kept exploring the fault to prove you
wrong, and in turn find the fault was my own.