Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Nov 14 18:08
    wqmeng commented #201
  • Nov 14 18:04
    arvanus commented #201
  • Nov 14 17:43
    wqmeng commented #201
  • Nov 14 17:37
    arvanus commented #201
  • Nov 14 17:31
    wqmeng commented #201
  • Nov 14 12:00
    arvanus commented #201
  • Nov 14 09:07
    wqmeng commented #201
  • Nov 14 09:05
    wqmeng commented #201
  • Oct 30 16:15
    rlebeau edited #260
  • Oct 16 04:22
    rlebeau labeled #269
  • Oct 16 04:22
    rlebeau opened #269
  • Oct 08 19:00

    Fulgan on Restructure

    Bug fix for a typo in TIdIMAP4.… (compare)

  • Oct 08 19:00

    Fulgan on master

    Bug fix for a typo in TIdIMAP4.… (compare)

  • Oct 02 21:00

    Fulgan on Restructure

    Updating TIdIMAP4's InternalSea… (compare)

  • Oct 02 21:00

    Fulgan on master

    Updating TIdIMAP4's InternalSea… (compare)

  • Sep 20 21:50

    Fulgan on master

    Embarcadero patch for race cond… (compare)

  • Sep 20 21:50

    Fulgan on Restructure

    Embarcadero patch for race cond… (compare)

  • Sep 10 18:50
    rlebeau closed #268
  • Sep 10 18:50
    rlebeau commented #268
  • Sep 10 18:50

    Fulgan on Restructure

    Fix for TIdResponseHeaderInfo.S… (compare)

fan_tangshan
@sainimu78
QQ图片20160811020720.png
Here is the common read write procedure
blob
fan_tangshan
@sainimu78
The server
blob
The client
blob
fan_tangshan
@sainimu78
So simple test it is, I believe you'd tested it at the very beginning
Remy Lebeau
@rlebeau
well, it kind of makes sense, if you take into account that the client code is single-threaded but the server code is multi-threaded, so you are likely getting task switches during the server-to-client sending that are slowing it down compared to the client-to-server sending. Remember, TIdTCPServer runs each client in its own worker thread. Even if there is only 1 client connected, there are still other threads running (the main UI thread, the server's listening thread, etc) that the OS has to service in a timely manner.
fan_tangshan
@sainimu78
No, I don't think so. It's normal when I test the client-server sending with fixed bytes.
There may have some bad implementations doing with that.
blob
fan_tangshan
@sainimu78
After doing the server-client sending test, every client-server sending makes CPU usage rate high. If you are listening music you can hear lag sound.
So I guess the non-fixed bytes sending causes some threads work so hard in TIdTCPServer if the TIdContext.Connection.IoHandler cached something when Write().
davidpn
@davidpn
I thought I cancelled Lex's post that you replied to in the .winsock group.. it was an out-and-out lie (a repeat of the same one, I know)
fan_tangshan
@sainimu78
Is it not a problem? @rlebeau
Remy Lebeau
@rlebeau
by default, the IOHandler does not cache anything when sending. The data is passed directly to the underlying socket and the OS does all of the caching
I don't know what elsee to tell you. There is no memory leak in Indy. Plenty of people use Indy for a long time, a leak would have been noticed before. Something else has to be going on in your environment. Maybe your test code is fragmenting memory instead of leaking it. who knows.
davidpn
@davidpn
What's the reasoning behind checking for PassThrough when catching the exception in TIdSSLIOHandlerSocketOpenSSL.StartSSL (IdSSLOpenSSL unit)?
The reason I ask is that when using SSL through a proxy, PassThrough is set to True, so it's impossible to catch the EIdOSSLCouldNotLoadSSLLibrary exception
Remy Lebeau
@rlebeau
At that stage, OpenSSL is simply being pre-initialized but SSL/TLS is not actually being used yet, and may or may not ever be used depending on the caller's needs, so the exception is silent caught to allow the unencrypted connection to proceed. At a later time, if PassThrough is ever set to false to activate SSL/TLS, then the exception will be raised to the caller. Even through a proxy, PassThrough has to be set to false eventually.
davidpn
@davidpn
OK.. I think the easiest way out is going to be to call Load before a connection is attempted
Remy Lebeau
@rlebeau
just make sure you call it in a thread-safe manner to avoid overlapping loads
davidpn
@davidpn
thanks
Ludwig Behm
@lbehm
Hy everyone, I'm trying to overwrite a response generated by datasnap (running on TIdHTTPWebBrokerBridge). TDSRESTWebDispatcher sends eventual StatusCode 401 and to hide the annoying browser login window, I want to send StatusCode 403 instead. After trying several DataSnap specific events which show absolutely no effect, I would like to try to intercept the response on the Indy-level.
Is there a nice way to hook into the server response and overwrite every StatusCode of 401 with 403? PS: I have access to an Intercept interface.
Remy Lebeau
@rlebeau
If you don't have access to the actual source that is populating the original HTTP response, you can't really change its behavior. With an Intercept, it might be possible to alter the data as it is being sent, but that would require parsing the HTTP data that passes through the Intercept. The data is arbitrary bytes from the Intercept's perspective, so you would need to write a stateful parser in case you get multiple OnSend events. I would be more inclined to suggest figuring out why DataSnap is sending a 401 reply to begin with and see if there is a way to change that behavior, instead of trying to modify the response data after the fact. Especially since modifying the 401 may break non-browser clients that could have logged in without prompting the user. Why are you using a web browser to access a DataSnap REST server in the first place?
Ludwig Behm
@lbehm
Thank you for the fast answer! I'm writing a AngularJS based browser-only-app and access the backend via the rest interface. And sadly I've found no possibility to circumvent either the browser behavior (showing the login box) or that of datasnap (sending 401 if TDSAuthenticationManager is present but no login/session data).
Remy Lebeau
@rlebeau
Sorry, I don't know anything about Angular or DataSnap or how they work.
Ludwig Behm
@lbehm
okay^^ do you maybe know of some other rest-framework which is compatible with c++builder? I just found a delphi based one =)
Remy Lebeau
@rlebeau
You can use Delphi code and Delphi components in C++Builder.
Or, you could just use TIdHTTPServer directly and implement your own REST logic on top of it
then you can send whatever responses you want
Paessler
@Paessler
Hi guys, do you know if there is any plan to upgrade indy for use with openSSL 1.1.0 Branch in the near future?
Remy Lebeau
@rlebeau
there is no immediate plan for that at this time. 1.1.0 introduces major API breakages over previous versions, I don't know what the level of effort will be yet to support the new API, especially in parallel with the earlier API.
1.1.0 was just officially released a few days ago, and 1.0.2 is not going away for several years. So there is time to migrate Indy to 1.1.0 eventually.
Paessler
@Paessler
yeah but browsing through all the API and Statemachine changes worries me a bit especially since we use a whole set of libraries depending on OpenSSL which is/was a fuzzle to keep in sync in the past. Thanks for your reply Remy
petesky
@petesky
Hi, http://indy.fulgan.com/SSL/ is not available anymore ?
Remy Lebeau
@rlebeau
It is still available, it just appears to be down right now. I have reported it.
Remy Lebeau
@rlebeau
It is working again
davidpn
@davidpn
@rlebeau Are you able to set up an IPv6 only network so you can verify that TIdHTTP can handle it? Alternatively, are you aware if it doesn't? This is for Indy 10 that comes with 10.1 Berlin.
Remy Lebeau
@rlebeau
@davidpn I have not verified it, and I am not aware of any issues that would prevent it from working.
davidpn
@davidpn
ok.. not sure if I can come up with steps for you.. you don't have a Mac, for example, yes?
Remy Lebeau
@rlebeau
I have a couple of OSX VMs, but I don't know if they have the option of creating an IPv6 network for testing. I'm trying to run one of them right now, but it is really slow
davidpn
@davidpn
perhaps if I detail where it breaks down.. I'm willing to spend a bit of time on it, because I'd prefer to keep using Indy, and right now at work it's a "must have" because we want to use TestFlight for external testing and I expect the app will be rejected if it fails IPv6 only. They're moving away from Indy after this prototype has lived out its life
Remy Lebeau
@rlebeau
my OSX VMs are too old. Creating an IPv6 network was added in El Capitan, but my VMs are Mountain Lion and Mavericks, which don't have the option.
davidpn
@davidpn
fair enough.. like I say, I'll look into it; more than likely before the end of the weekend. It has risen high on my to-do list
Wil32
@Wil32
i have a el capitan vm. you a wireless adapter to make the whole thing work. just follow apple's doc.
davidpn
@davidpn
I know how to make a IPv6 only network.. it's making TIdHTTP work with it that is the problem
I didn't get far over the weekend with diagnosing the problem, however my initial guess is that it simply doesn't switch to IPv6 if IPv4 doesn't work (or cannot detect IPv6 only)
Remy Lebeau
@rlebeau
Indy does not switch automatically, you have to tell it which IP version to use ahead of time. By default, everything it does uses IPv4 unless told otherwise. In IdCompilerDefines.inc, you can set the default to IPv6 instead (that is what Embarcadero did for their iOS bundled version of Indy). Alternatively, you would have to manually detect the network IP version and then configure Indy accordingly at runtime when making connections.
Since you mention TIdHTTP, I suspect it is treating your URLs as IPv4 unconditionally. For IPv6, you have to wrap hostnames in brackets, eg: http://[hostname]:port/resource. If you get an HTTP redirect to a different hostname, that might switch back to IPv4. I will have to check that.