I can get all local IP addresses using this code with indy:
uses IdStack;
var
IPs: TStringList;
begin
IPs := TStringList.Create;
try
GStack.AddLocalAddressesToList(IPs);
listbox_localIPs.Items.Assign(IPs); //My listbox
finally
IPs.Free;
end;
end;
How can I get Adapter Name for each IP I find with Indy?
Indy doesn't provide such info. You must use WinApi (GetAdaptersInfo, GetAdaptersAddresses) or WMI (Win32_NetworkAdapter).
Indy is primarily just a wrapper around standard socket APIs that do not expose adapter information. AddLocalAddressesToList() uses platform-specific APIs to get the local IPs, and some of those APIs may report adapter names (or expose ways to look up those names through other APIs), but AddLocalAddressesToList() simply fills a TStrings with IP address strings, so it has no way of reporting adapter names even if it wanted to.
With that said, AddLocalAddressesToList() has recently been deprecated in favor of a new GetLocalAddressList() method, which returns a collection of TIdStackLocalAddress-derived objects containing additional information (IP version, subnet mask). So it is feasible that a future release might add adapter names, but that would still be implemented on a platform-specific basis and thus may not be available on all platforms. Indy itself does not need adapter names, so you are best off simply using platform-specific APIs directly to get whatever adapter information you need.
Related
How to trace all events for service firebird server with delphi xe10?
This is my code:
my := TIBControlService.Create(Self);
my.ServerName := '127.0.0.1/3050';
my.Protocol := TProtocol.TCP;
my.LoginPrompt := false;
my.TraceFlags := [tfQPrepare, tfQExecute, tfQFetch, tfError, tfStmt, tfConnect, tfTransact, tfBlob, tfService, tfMisc];
my.Params.Add( 'user_name=SYSDBA' );
my.Params.Add( 'password=masterkey' );
// -----
mh := MonitorHook;
mh.TraceFlags := my.TraceFlags;
Self.IBSQLMonitor1.TraceFlags := my.TraceFlags;
mh.RegisterMonitor(Self.IBSQLMonitor1);
Self.IBSQLMonitor1.Enabled := true;
Memo1.Lines.Add( Format('GetMonitorCount: %d',[mh.GetMonitorCount]) );
my.Attach;
Memo1.Lines.Add( Format('Active: %s',[System.StrUtils.IfThen(my.Active,'yes','no')]) );
and
procedure TForm1.IBSQLMonitor1SQL(EventText: string; EventTime: TDateTime);
begin
Memo1.Lines.Add(EventText);
end;
Result:
GetMonitorCount: 1
Active: yes
[Application:]
:[Attach]
[Application:]
:[Query]
But this result is only from my application. When I connecting from another proces (ex.isql) my application not show this event.
When talking about Interbase/Firebird the term EVENT has a very specific meaning, the specific SQL command that sends text constants to clients, who subscribed to those.
See http://firebirdsql.org/file/documentation/reference_manuals/fblangref25-en/html/fblangref25-psql-coding.html#fblangref25-psql-postevent
However, the client should subscribe to the exactly the same text string, as posted by PSQL block. There were talks about enabling masks-based subscription, which would potentially made it possible to subscribe to all SQL events, like *.* matches all files in Windows, but for the best of my knowledge they never materialized.
That is what "event" means in Firebird, but it does not seem that is what you mean, instead it looks you want to monitor all the kinds of activity flowing between the SQL server and all the applications, starting with SQL commands and more.
If so, then there is no way to do it in general. You have to decide what exactly and why exactly do you want, and maybe there will be some partial solutions.
Firebird 2.5 introduced the so called Trace API, which allows you to subscribe to SOME of actions and be notified of them. This tends to introduce a significant load on the engine though, depending on how vague your subscription filters would be and how many requests the server receives - it might increase RAM and CPU usage up to total unusability.
The kinds of activity that can be subscribed for are limited. For example the process of reading BLOBs is not monitored. When I asked - I was struggling with the infamous "Invalid BLOB id" that was triggered by Delphi dbExpress library quirk - i was told that "no one ever needed this, and you have little reasons to need it too. You made a demo project, sent it to us - and we explained the behavior for you". THAT time having BLOBs access tracing would help me a lot, but to be objective, that was one and the only case I really needed it.
You might take a look at what you can get in general with Firebird Trace Manager - a CLI utility that is part of FB distribution, starting with 2.5.
You might take a look at Firebird Profiler, a free simplistic GUI tool from http://fbprofiler.sf.net
Commercial DB IDEs for Firebird, like IBExpert or UpScene TraceManager and probably others too, usually have Trace API support.
You may do your own implementation, using Trace API, starting with Program Files\Firebird\Firebird_2_5\doc\README.trace_services.txt and Program Files\Firebird\Firebird_2_5\include\ibase.h. It may also happen that 3rd party libraries like Unified Interbase or IBObjects have translated the API to Delphi. I think i saw something about trace in UIB but i am not sure. I would not expect though such a library to be part of Delphi distribution: from Delphi standpoint Firebird is direct competitor to their Interbase and IBX library would hardly have interest to diverge from their own Interbase by supporting Firebird-only functions.
Provided you only care about native applications like Delphi you might decide to make your own interposer fbclient.dll and install it on all the client computers instead of stock DLLs. Same for legacy-emulating GDS32.DLL, if used by your apps.
This DLL should totally provide all the API calls, both classic ones described in IB6 documentation at http://firebirdsql.org/en/reference-manuals/ with all the post-IB6 updates, and the new Firebird 3 "object oriented API".
It should log the calls in a way of your choosing, and then should proxy the call to the copy of original client DLL that you will hide for it with different file name. It should be installed instead of the standard client DLL on every computer you care to intercept and monitor.
It should not be very hard with the classic API, people were doing this, though did not publish. But the new ooAPI might be challenging.
It will only intercept applications, working through the fbclient.DLL interface. Java applications using Jaybird and C# applications using .Net Provider libraries would probably use underlying wire protocol skipping the fbclient.dll and thus your interposer too.
I am converting a unit that holds a network interface list to be cross platform. The current version uses raw winsock to obtain the address, mask and broadcast address for each network interface in the system.
I figure the easiest way to make this cross platform is to use Indy. I have found that AddLocalAddressesToList is a nice simple way to get the IP address of all the interfaces but I cannot find out how to get the other information I need (mask and broadcast address).
I think I can calculate the broadcast address so its really just the mask that I cant figure out.
FYI. This is the code I found to get the IP addresses of all interfaces.
TIdStack.IncUsage;
try
GStack.AddLocalAddressesToList(Memo1.Lines);
finally
TIdStack.DecUsage;
end;
WinSock does not support reporting that kind of info. You have to use OS-specific APIs instead. On Windows, that means using the Win32 API GetAdaptersInfo() and GetAdaptersAddresses() functions. On other platforms, you can use the getifaddrs() function where available.
Indy does not currently support what you are asking for. Also, do note that at this time, AddLocalAddressesToList() only supports IPv4 addresses on most platforms, including Windows.
Support for retreiving local IPv6 addresses, as well as other info like subnet masks, is currently in the works, but there is no ETA on its availability yet.
I use WM_COPYDATA to enable communication between my two processes A and B. There is no problem to exchange data with basic data types.
Now I have a problem, in some case I want to pass an Interface (IDispatch) from my process A to my process B. Is it possible?
It is not possible to directly pass an interface pointer to another process. Like any other pointer, an interface is only valid in the process address space that instantiates it at runtime. COM has its own mechanism for marshaling interfaces and data across process boundaries, even across different apartments in the same process. In the case of interfaces, that involves proxies and stubs which run in each process/apartment and communicate with each other using various IPC mechanisms, such as pipes, RPC, or TCP/IP. Have a look at these articles for how using interfaces across processes/apartments is accomplished:
Inter-Object Communication
Understanding Custom Marshaling Part 1
To do what you are asking for, without resorting to implementing custom marshaling, you would have to make one of the processes act as an out-of-process COM server, and then the other process can use CoCreateInstance() or GetActiveObject() to obtain an interface pointer to the server's object that works within its local address space, and let COM handle the marshaling details for you.
It can't be done directly, but you can use a Client-Server service framework, which may be interface based.
For instance, see the last feature of our Open Source mORMot framework: Interface based services sample code and this link.
You can execute an interface on a remote process. The feature handles all communication means of the framework, i.e. in-process call, GDI messages, named pipes and TCP/HTTP. Internally it will use WM_COPYDATA for GDI messages, then transmit the parameters and results as JSON. Use this link to download the source code (use the http://synopse.info/fossil 1.16+ version) and the documentation (there are several pages about how to implement those services).
It is an Open-Source project, working with Delphi 6 up to XE2.
You can also expose your interface with a SOAP or DataSnap Client-Server (if you have the corresponding version of Delphi), or n-Tier commercial packages (like http://www.remobjects.com/da). This is similar to the method implemented in mORMot.
COM is also a good candidate, native to Windows, but it is more difficult to initialize: you'll have to register the COM on each PC (with administrator rights), and you won't be able to make it work over a network (DCOM is deprecated, remember). COM is good if you want your service to be shared with other languages, like .Net, but only locally.
As you know Proxifier is a program that allows network applications that do not support working through proxy servers to operate through an HTTPS or SOCKS.
It can handle any transmission from running applications. I want to know how it can do this and how I can write one like that.
FreeCap is your way to go.
It's released under GNU General Public Licence and written in Delphi.
A socksifier defines a dynamic library with the same functions as the OS socket layer, but defined in such a way as to use a socks proxy. The program being socksified uses that library instead of the OS-supplied one for its network communication.
I am trying out some IP PBX systems, Asterisk, Freeswitch, and Yate,to register for events in the PBX, and I want to know which of these components is the better one.
The component is supposed to register with the PBX for events, receive them, send some responses and issues some commands. Which of the two would be the more appropriate?
The difference between a TCP server and client is who initiates the connection. The client connects to the server. So I'm guessing you should use the TIdTCPClient.
Asterisk has a well-defined network TCP/IP event-driven protocol which supports SSL communications. This module is called the Asterisk AMI, and is widely used to do exactly what you want.
You can read the documentation on the AMI here: http://www.voip-info.org/wiki/view/Asterisk+manager+API
Also, if you want to check out some products which use the AMI events as their core product, check out:
Flash Operator Panel http://www.fop2.com/
HUD http://www.fonality.com/products/hud
Asterisk Assistant http://blogs.digium.com/2008/12/22/asterisk-desktop-assistant-windows-click-to-call-and-more/
Enjoy :)
Another option would be to use Synapse which is a blocking TCPIP library which is very easy to use and supports free pascal, as well as Delphi.