RTC Forums
November 23, 2024, 05:10:00 PM *
Welcome, Guest. Please login or register.

Login with username, password and session length
 
   Home   Help Login Register  
Pages: [1]
  Print  
Author Topic: rtcHttpServer port assignment  (Read 6759 times)
ClementDoss
RTC License
***
Posts: 36


« on: November 02, 2017, 09:28:11 PM »

Hi,

I'm using Delphi Tokyo and RTC v9.
I wrote a Windows Service REST server using RTC that works at home, but not at my customer's lol.
Well, this is my code for setting up the server:

Code:
procedure TRestServer.DoConfigRESTServer;
begin
  FRestServer.ServerAddr := '';
  FRestServer.ServerPort := Port.ToString ; //## Setting loaded from INI
  FRestServer.MultiThreaded := True;
  FRestServer.RestartOn.ListenLost := True;
end;


function TRestServer.DoConnect: Boolean;
begin
  DoConfigRESTServer;
  FRestServer.Listen;
  result := True;
end;

The server is using port 8083. I have created in the same project group, two projects:
    
  • Test Server (Simple form with a Start/Stop server button)
  • The Service.

Both are sharing the class class that declares and assigns rtchttpServer using the code I show above.
In my office, when I run netstat -ano both the test server and the service displays correctly the port beeing used (running one at a time of course). For example:
  TCP    0.0.0.0:8083           0.0.0.0:0              LISTENING       7272

My customer's has a Google VM machine hosted in google cloud. When I run the Test server, netstat displays what's expected. But when I install and start the service another port is used (Huh)

When the Service is running netstat displays:

  Proto  Local Address          Foreign Address        State           PID
  TCP    0.0.0.0:135            0.0.0.0:0              LISTENING       612
  TCP    0.0.0.0:445            0.0.0.0:0              LISTENING       4
  TCP    0.0.0.0:3389           0.0.0.0:0              LISTENING       1812
  TCP    0.0.0.0:5986           0.0.0.0:0              LISTENING       4
  TCP    0.0.0.0:10088          0.0.0.0:0              LISTENING       1556
  TCP    0.0.0.0:16000          0.0.0.0:0              LISTENING       1556
  TCP    0.0.0.0:17000          0.0.0.0:0              LISTENING       1556
  TCP    0.0.0.0:47001          0.0.0.0:0              LISTENING       4
  TCP    0.0.0.0:49152          0.0.0.0:0              LISTENING       336
  TCP    0.0.0.0:49153          0.0.0.0:0              LISTENING       704
  TCP    0.0.0.0:49154          0.0.0.0:0              LISTENING       744
  TCP    0.0.0.0:49158          0.0.0.0:0              LISTENING       432
  TCP    0.0.0.0:49162          0.0.0.0:0              LISTENING       440
  TCP    0.0.0.0:49217          0.0.0.0:0              LISTENING       1868
  TCP    10.142.0.2:139         0.0.0.0:0              LISTENING       4
  TCP    10.142.0.2:3389        186.203.1.225:52459    ESTABLISHED     1812
  TCP    10.142.0.2:16000       10.142.0.2:49275       ESTABLISHED     1556
  TCP    10.142.0.2:16000       10.142.0.2:49276       ESTABLISHED     1556
  TCP    10.142.0.2:49157       169.254.169.254:80     ESTABLISHED     1124
  TCP    10.142.0.2:49275       10.142.0.2:16000       ESTABLISHED     2764 (*)
  TCP    10.142.0.2:49276       10.142.0.2:16000       ESTABLISHED     2764 (*)
  TCP    [::]:135               [::]:0                 LISTENING       612
  TCP    [::]:445               [::]:0                 LISTENING       4
  TCP    [::]:3389              [::]:0                 LISTENING       1812
  TCP    [::]:5986              [::]:0                 LISTENING       4
  TCP    [::]:47001             [::]:0                 LISTENING       4
  TCP    [::]:49152             [::]:0                 LISTENING       336
  TCP    [::]:49153             [::]:0                 LISTENING       704
  TCP    [::]:49154             [::]:0                 LISTENING       744
  TCP    [::]:49158             [::]:0                 LISTENING       432
  TCP    [::]:49162             [::]:0                 LISTENING       440
  TCP    [::]:49217             [::]:0                 LISTENING       1868

(PID is 2764)

When Test server is running (Form with buttons) netstat displays:
  Proto  Local Address          Foreign Address        State           PID
  TCP    0.0.0.0:135            0.0.0.0:0              LISTENING       612
  TCP    0.0.0.0:445            0.0.0.0:0              LISTENING       4
  TCP    0.0.0.0:3389           0.0.0.0:0              LISTENING       1812
  TCP    0.0.0.0:5986           0.0.0.0:0              LISTENING       4
  TCP    0.0.0.0:8083           0.0.0.0:0              LISTENING       1588 (*)
  TCP    0.0.0.0:10088          0.0.0.0:0              LISTENING       1556
  TCP    0.0.0.0:16000          0.0.0.0:0              LISTENING       1556
  TCP    0.0.0.0:17000          0.0.0.0:0              LISTENING       1556
  TCP    0.0.0.0:47001          0.0.0.0:0              LISTENING       4
  TCP    0.0.0.0:49152          0.0.0.0:0              LISTENING       336
  TCP    0.0.0.0:49153          0.0.0.0:0              LISTENING       704
  TCP    0.0.0.0:49154          0.0.0.0:0              LISTENING       744
  TCP    0.0.0.0:49158          0.0.0.0:0              LISTENING       432
  TCP    0.0.0.0:49162          0.0.0.0:0              LISTENING       440
  TCP    0.0.0.0:49217          0.0.0.0:0              LISTENING       1868
  TCP    10.142.0.2:139         0.0.0.0:0              LISTENING       4
  TCP    10.142.0.2:3389        186.203.1.225:52459    ESTABLISHED     1812
  TCP    10.142.0.2:16000       10.142.0.2:49274       ESTABLISHED     1556
  TCP    10.142.0.2:49157       169.254.169.254:80     ESTABLISHED     1124
  TCP    10.142.0.2:49274       10.142.0.2:16000       ESTABLISHED     1588
  TCP    [::]:135               [::]:0                 LISTENING       612
  TCP    [::]:445               [::]:0                 LISTENING       4
  TCP    [::]:3389              [::]:0                 LISTENING       1812
  TCP    [::]:5986              [::]:0                 LISTENING       4
  TCP    [::]:47001             [::]:0                 LISTENING       4
  TCP    [::]:49152             [::]:0                 LISTENING       336
  TCP    [::]:49153             [::]:0                 LISTENING       704
  TCP    [::]:49154             [::]:0                 LISTENING       744
  TCP    [::]:49158             [::]:0                 LISTENING       432
  TCP    [::]:49162             [::]:0                 LISTENING       440
  TCP    [::]:49217             [::]:0                 LISTENING       1868

What happened to my 8083 port?

What am I missing?

TIA,
Clément


Logged
D.Tkalcec (RTC)
Administrator
*****
Posts: 1881


« Reply #1 on: November 03, 2017, 09:51:32 AM »

My guess is that you are loading the wrong INI file when the Application is running as a Windows Service and "Port.ToString" returns an empty String (or raises an exception) and the Server does NOT start.

Make sure to include the full path to any file you are loading (do NOT use relative paths), because the default path will be inside the Windows folder when your Application is running as a Windows Service instead of the folder where your EXE file is placed. You can use "AppFileName" (global variable declared in the "rtcSystem" unit in RTC SDK v9) to get the full name and path of your EXE file and use that as your "root".

If that is NOT the problem, then it could also be some permission issue (security policy set up by default on Google Servers?). In either case, you should implement the "OnListenError" event (on the "TRtcHttpServer" component) to log the Exception Message in case of an Error while starting the Server listener, and ... implement the "OnListenStart" event to log the actual Port being used when the Server does start. Both of these events could help identify the problem.

PS. You can also declare the RTC_DEBUG compiler define to enable debugging for exceptions raised by the RTC SDK (you can do this in the "rtcDeploy.inc" file in the RTC SDK "Lib" folder or in your Project Options), and ... you can use the "Log()" function from the "rtcLog" unit to write any information that might help you debug the problem, if you aren't already using something else for "debug logging".

Best Regards,
Danijel Tkalcec
Logged
ClementDoss
RTC License
***
Posts: 36


« Reply #2 on: November 03, 2017, 07:49:13 PM »

Well,

I'm still lost. I'm running the same service in my office's Windows Server 2008 and it works. I can change ports restart the service. The log displays that the server port is assigned correctly.

Another point. I'm using ICS UDP component in the same server (to handle UDP request). In case of ICS I must specify '0.0.0.0' as the server address. When I start the service at Google's VM, the TCP port 8083 is not displayed ( no error is raised by the events OnListenError ), in fact ListenStart is triggered as my log shows the service is active. UDP port is displayed by netstat. I also tryied setting ServerAddr to '0.0.0.0' but still no joy.

In "my server" everything is working as expected. So both rtcHTTp and ICS UDP are getting their configuration and are bound to the correct ports...

Tough Friday  Huh
Logged
D.Tkalcec (RTC)
Administrator
*****
Posts: 1881


« Reply #3 on: November 03, 2017, 09:11:30 PM »

Are you saying that the "OnListenStart" event is triggered on the "TRtcHttpServer" component and that "Sender.LocalPort" has the correct port number inside that event, but that the Server is NOT listening? And the “OnListenLost” or the “OnListenStop” event did NOT get triggered, to indicate that the Server was stopped?

Well, that would be the first.

What you could try, is to set the "Blocking" property on the "TRtcHttpServer" component to TRUE (it should be FALSE by default). This would make the Server use a blocking WinSock API instead of Async WinSock, to rule out a possible conflict with ICS (which is using Async WinSock).

Let me know if that changes anything.

Best Regards,
Danijel Tkalcec
Logged
Chris@Xenos
RTC Expired
*
Posts: 3


« Reply #4 on: November 04, 2017, 07:01:31 AM »

Maybe this is because of a third party software like an antivirus or firewall? Not the windows firewall.
Just a thought out of the box.
Logged
ClementDoss
RTC License
***
Posts: 36


« Reply #5 on: November 04, 2017, 03:12:13 PM »

Hi Danijel

You nailed it.
Quote
What you could try, is to set the "Blocking" property on the "TRtcHttpServer" component to TRUE (it should be FALSE by default). This would make the Server use a blocking WinSock API instead of Async WinSock, to rule out a possible conflict with ICS (which is using Async WinSock).[/i]

This is the log. I compiled the project twice. Once with blocking True. And the other with blocking false:
-- Using Blocking = True
23:42:59.977     Creating Rest Server v1.01 instance
23:43:01.792     Preparing connection
23:43:01.792      Bind to port 8083
23:43:01.793      DHS Rest Server listenning to port 8083
23:43:01.793      ListenStart 0.0.0.0, 8083, DHSCLOUD1
23:43:01.794      ListenStop
23:43:15.264      Disconnecting  ( I disconnected here )
-- Using Blocking = False
23:44:59.701     Creating Rest Server v1.01 instance
23:45:00.996     Preparing connection
23:45:00.996      Bind to port 8083
23:45:00.996      DHS Rest Server listenning to port 8083
23:45:00.998      ListenStart 0.0.0.0, 8083, DHSCLOUD1
23:45:26.274      Disconnecting  (I Disconnected here)
23:45:26.274     ListenStop


My UDP server must be conflicting with rtcHTTP. I will disable it and see what happens.

Clément
Logged
ClementDoss
RTC License
***
Posts: 36


« Reply #6 on: November 04, 2017, 11:10:05 PM »

Hi,

It was in fact a conflict between ICS and RTC. Very likely something terribly wrong I wrote. Anyway, I replaced ICS UDP server with RTC and everything is working fine!

Thanks for your help

Clément
Logged
D.Tkalcec (RTC)
Administrator
*****
Posts: 1881


« Reply #7 on: November 05, 2017, 08:11:05 AM »

Perfect. Thank you for your feedback.

Best Regards,
Danijel Tkalcec
Logged
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Valid XHTML 1.0! Valid CSS!
Page created in 0.03 seconds with 17 queries.