Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About Fr0sT.Brutal

  1. I've never dealt with IPv6 but for me the purpose of this piece а code is to 1) assign v6 family from v6 IP address so that a user doesn't have to specify the family manually and 2) if IP is v6 check that OS supports it. And I'm not sure whether 2) is necessary, maybe it would fail later anyway on address resolution.
  2. I suspect the logic here should be If address is IP then if IP is v4 or v6 available then Ffamily := Lfamily else Error('IPv6 not supported') so that it 1) assigns proper FFamily and 2) checks for v6 availability.
  3. Angus, seems it got. { V8.56 IPv6 support from Max Terentiev } if WSocketIsIP(FSocksServer, LSocketFamily) then begin // is socks proxy IP is IPv6 ? if (LSocketFamily = sfIPv4) or (IsIPv6APIAvailable) then FSocketFamily := LSocketFamily else FSocketFamily := DefaultSocketFamily; end else raise ESocketException.Create('Unsupported socks address format'); Current value of FSocketFamily is not considered
  4. HTTP Tunnel and Socks server addresses can not have literal address (including 'localhost') because IPv6 check in `procedure TCustom*WSocket.Connect` throws 'Unsupported address format'. I suppose this check should only test for unavailable IPv6 case (i.e. address is IPv6 but OS doesn't support it).
  5. Fr0sT.Brutal

    Can't build packages without SSL

    Angus, I use the fresh trunk from SVN. In most cases, enclosing all unit contents in IFDEF will help (just like OverbyteIcsLIBEAY f.ex.) And #4 happens with SSL, maybe your Delphi allows this? Mine XE2 refuses to override non-virtual methods (and it is obviously right)
  6. I have latest SVN version. First of all, `USE_SSL` is uncommented by default in defs.inc so a user has to edit defs file otherwise he can't control this option. Second, without `USE_SSL` ICS packages couldn't be built as following units have incorrect defines sections: OverbyteIcsSslX509Utils in '..\Source\OverbyteIcsSslX509Utils.pas', OverbyteIcsLibeayEx in '..\Source\OverbyteIcsLibeayEx.pas', OverbyteIcsProxy in '..\Source\OverbyteIcsProxy.pas', OverbyteIcsSslJose in '..\Source\OverbyteIcsSslJose.pas', OverbyteIcsSslHttpRest in '..\Source\OverbyteIcsSslHttpRest.pas', OverbyteIcsSslX509Certs in '..\Source\OverbyteIcsSslX509Certs.pas', OverbyteIcsIpStreamLog in '..\Source\OverbyteIcsIpStreamLog.pas', OverbyteIcsMailQueue in '..\Source\OverbyteIcsMailQueue.pas', OverbyteIcsHttpMulti in '..\Source\OverbyteIcsHttpMulti.pas', OverbyteIcsFtpMulti in '..\Source\OverbyteIcsFtpMulti.pas', Third, unit `OverbyteIcsHttpAppServer` can't be built as well as it uses `ClientCnx.HostTag` that is unavailable without SSL Fourth, `TSslWSocketClient` has `TriggerSslAlpnSelect` overridden method that is not virtual in base `TWSocketClient` so compiler produces build failure.
  7. Francois, of course this will do the trick but this means client code must meet some requirements which doesn't seem reliable to me. Angus, well, have exceptions raised and shown could sound bad but it's really much better than have them swallowed silently IMHO. Unawareness of errors could cause mysterious AVs and other non-relative errors in random places. And all systems that claim to be robust should have bg exceptions handler already ¯\_(ツ)_/¯
  8. Hi all, spent some time just now on investigating a weird bug, it happened to be a memory AV that wasn't reported or caught by my exception handlers. Finally I came to see TCustomWSocket.ASyncReceive which appeared to just silently swallow any exceptions that happen in TriggerDataAvailable. I suppose it should have HandleBackGroundException(E) shouldn't it? Ver.: 8.58 File: OverbyteIcsWSocket.pas Line: 8427