Jump to content

philipp.hofmann

Members
 View Profile  See their activity

  • Content Count

    69

  • Joined

  • Last visited

Posts posted by philipp.hofmann

  1. Posted

    Hi Remy,

    a) I've checked now with "netstat -an".

     

    On MacOS10 I get the following entries:

     

    Proto  Recv-Q Send-Q Local Address           Foreign Address        (state)

    tcp4    0           0           *.2020                       *.*                              LISTEN
    udp4   0          0            *.2020                       *.*

     

    On MacOS11 I get the following entry only:

    Proto  Recv-Q Send-Q Local Address           Foreign Address        (state)

    tcp4    0           0           *.2020                       *.*                              LISTEN

    but there is no entry for *.2020.

     

    I can see with Wireshark-Packet-Sniffer that the UDP package for Port 2020 is there but not read on MacOS11 computer.

     

    Best regards, Philipp

  2. Posted

     

    On 6/14/2021 at 6:31 PM, Remy Lebeau said:

    Did you verify that your UDP listening port is actually open, and that inbound data is actually reaching that port?  If Select() returns false, it means the underlying OS reported that no data was available before the specified timeout had elapsed.  What is your AcceptWait set to exactly?

    Hi Remy,
    do you have any other idea what to check on my side to solve the MacOS11 issue?
    Can you reproduce on your side the issue with MacOS11?
    Best regards, Philipp

  3. Posted

    The command "nc -vnzu 192.168.10.30 2020-2040" returns "[udp/*] succeeded!" for all ports. But also if the app is not running yet and it's the same response on MacOS 10 as on MacOS 11.
    I'm using the Delphi-Tethering-implementation and it looks like Start-Listing was successful. 
    FAcceptWait contains the default value, so 1000.

     

    I'm wondering if there is any new setting to use for MacOS 11 (e.g. capabilities). I know the Multicast-capability yet but this is only for iOS14.x.

     

  6. Posted

    Hi,

    even after adding the new Apple Multicast-Entitlement it's not possible to use Tethering with MacOS 11.x and iOS 14.x devices on server side. This devices will not be found with the method 
    TTetheringManager.DiscoverManagers
    requested on client side.

    It's fine with MacOS 10.x and iOS 13.x devices on server side. 

    You can test this also with the samples
    - DesktopWallApp (server)
    - MobilePhotoApp (client)

     

    DesktopWallApp Windows Android MacOS 10.x iOS 13.x MacOS 11.x iOS 14.x
    MobilePhotoApp            
    Windows OK OK OK OK not OK not OK
    Android OK OK OK OK not OK not OK
    MacOS 10.x OK OK OK OK not OK not OK
    iOS 13.x OK OK OK OK not OK not OK
    MacOS 11.x OK OK OK OK not OK not OK
    iOS 14.x OK OK OK OK not OK not OK

     

    The reason is that the method
    TTetheringNetworkManagerCommunicationThread.DoOnReceiveData
    is never reached with this OS versions.

    This problem crops the usage of Tethering as the biggest part of MacOS/iOS devices are running with the newest OS-version. So Tethering is usable for Windows and Android only.

     

    Do anybody knows a solution for this.

     

    Best regards, Philipp

     

    Activity

  9. Posted · Edited by philipp.hofmann

    The error occurs in IdGlobalProtocols.TimeZoneBias:

      

    function TimeZoneBias: TDateTime;
{$IFNDEF FPC}
  {$IFDEF UNIX}
var
  T: Time_T;
  TV: TimeVal;
  UT: {$IFDEF USE_VCL_POSIX}tm{$ELSE}TUnixTime{$ENDIF};
  {$ELSE}
    {$IFDEF USE_INLINE} inline; {$ENDIF}
  {$ENDIF}
{$ELSE}
  {$IFDEF USE_INLINE} inline; {$ENDIF}
{$ENDIF}
begin
{$IFNDEF FPC}
  {$IFDEF UNIX}
                                                                     
  {from http://edn.embarcadero.com/article/27890 }
  gettimeofday(TV, nil);
  T := TV.tv_sec;
  localtime_r({$IFNDEF USE_VCL_POSIX}@{$ENDIF}T, UT);
// __tm_gmtoff is the bias in seconds from the UTC to the current time.
// so I multiply by -1 to compensate for this.
  Result := (UT.{$IFNDEF USE_VCL_POSIX}__tm_gmtoff{$ELSE}tm_gmtoff{$ENDIF} / 60 / 60 / 24);
  {$ELSE}
  ...

     

    If I replace this with the following it's fine: 

    function TimeZoneBias: TDateTime;
{$IFNDEF FPC}
  {$IFDEF UNIX}
    var nowDt:TDateTime;
  {$ELSE}
    {$IFDEF USE_INLINE} inline; {$ENDIF}
  {$ENDIF}
{$ELSE}
  {$IFDEF USE_INLINE} inline; {$ENDIF}
{$ENDIF}
begin
{$IFNDEF FPC}
  {$IFDEF UNIX}
  nowDt:=NOW;
  Result := TTimeZone.Local.ToUniversalTime(nowDt)-nowDt;
  {$ELSE}
  ...  

    So it's fine for iOS and Android. For Android/FireOS there seems an additional issue with Delphi 10.3.3.

  10. Posted

    For me it's fine to compare with UTC time but the documentation of TIdTime says "DateTime is expressed in the timezone for the local computer". 
    And for Windows it's matching the documentation and for Android/iOS it's not matching the documentation. That's the point. 

     

    In my case I need to know the difference between the local timestamp and the server timestamp. That's the reason to use TIdTime.
    On Windows it's working fine, if the local time of computer A is 90 seconds ahead and of computer B it's 10 behind, I know that both computer's have a difference of 100 seconds and I have to keep this in mind for all synchronizations between both computers (it's a synchronization of video-play and it's should be insync with an accepted difference of +/-3 seconds.

    That's working as expected with my routine.

  11. Posted

    Hi,

     

    I'm using TIdTime to synchronize the time for an online process but it's not working as expected:

     

    Documentation TIdTime.DateTime:
    - DateTime is a read-only TDateTime property that reflects the estimated current date and time according to a Time server.
    - DateTime is expressed in the timezone for the local computer.

      

    procedure TicTrainerF.syncTime();
var idTime:TIdTime;
    dtLocal1,dtLocal2,dtServer:TDateTime;
begin
  idTime:=TIdTime.create(nil);
  idTime.Host:='time.nist.gov';
  dtLocal1:=NOW;
  dtServer:=idTime.dateTime;
  dtLocal2:=NOW;
  mlog.info('syncTime: '+DateToStr(dtLocal1,myFormatSettings)+'/'+DateToStr(dtLocal2,myFormatSettings)+' vs '+DateToStr(dtServer,myFormatSettings));
  ...

    It's fine for my windows-computers, so I can use it here.

     

    1. But it's wrong for Android and iOS as the time is returned in UTC instead of the local time zone.

    -> Question A: Is there a fixed rule for this so that it's always in UTC for this OS?

     

    2. On my Amazon FireHD-10 tablet (FireOS/Android) I get something completly different. 

    -> Question B: Was is the reason for completly different results here?


    incorrect (timezone):
    ---------------------
    syncTime (Android):        2021-01-18 16:24:50.789-16:24:51.169 vs 2021-01-18 14:24:51.000
    syncTime (Android):        2021-01-18 16:24:48.071-16:24:48.428 vs 2021-01-18 14:24:49.000
    syncTime (iOS):               2021-01-18 16:24:49.658-16:24:49.996 vs 2021-01-18 14:24:50.000

     

    incorrect (at all):
    -------------------
    syncTime (FireOS/Android): 2021-01-18 16:24:48.606-16:24:49.028 vs 2021-01-18 14:40:02.000


    correct:
    --------
    syncTime (Windows):        2021-01-18 16:24:47.612-16:24:48.359 vs 2021-01-18 16:24:48.000
    syncTime (Windows):        2021-01-18 16:24:46.014-16:24:46.771 vs 2021-01-18 16:24:47.000
     

    It's important for me that I can rely on the synchronization, else it's better to skip it and ask the user to take care of it.

     

    Are there idea how to improve this synchronization?

     

    Best regards, Philipp

×