Does anybody know how to limit/control the bandwidth of twsocket (client) in ICS components in Delphi? We have a small program that maps a port to squid. The software using ICS components that carries requests from the LAN arrives at one port to the port of squid, and returns the contents back to the originating IP. Can somebody shed some light as how to control the bandwidth to limit to certain KB/s, to keep bad boys out from using whole resources? Some code snippets may be highly appreciated.
Thanks in advance.
It is descriped in then FAQ (look for "Bandwidth control").
http://users.telenet.be/sonal.nv/ics/faq/Frame_index.html
There is also a link to a component implementing it
It seems you ar trying to simulate network constraints.
The are several comercial applications for that purpose, that also simulate latency (thats another common problem in wans).
Example of the Comercial applications are: Netlimiter, Shunra
Related
I am working on my thesis right now and i have to compare near field communication technologies (WPAN) which can transfer files.
everybody is talking how great UWB is for locating things and how fast it is, but there is no one (but apple) that used it for file transmission. But why? Its has a bigger bandwith then Wifi Peer to Peer?
Apple seems to use it for airdrop and both for android and ios there is an API to develop based on this technology. But it looks that its designed for location services and only work with specific devices for location. So I would not be able to use it for example to transfer files between iOS/Android and a Raspberry Pi in Near Field.
Can anyone explain me, if UWB can transfer files and, or why i should use Wifi-Direct instead of UWB if I want to transfer Files that are >1GB with the fastest speed (but without internet of course)
Thank you very much
IR-UWB is more popular than MC-UWB
UWB modulation schemes can broadly be divided into two categories
multi-carrier UWB (MC-UWB): used for high throughput data transmission, 480 Mbps
impulse-radio UWB (IR-UWB): used for localization, sensing.
I am currently working on an application which have to determine the type (CONNECT, Socks4, Socks5 etc.) of one or more given proxies and connect through them.
Unfortunately I have no approach to reach my goals and hope somebody can help me.
I saw in a tool (GSA SEO Indexer) that this bahvior is somehow possible. The tool has a built-in proxy finder and checker which is able to determine the proxy type:
I am using Delphi XE7 w/ Indy.
There are proxy detection protocols available, such as WPAD. You can use that to obtain details about proxies on a WPAD-enabled network, and then you can connect to them as needed.
I'm nxj beginner.
I have some questions about bluetooth communication between PC and brick.
First, when bluetooth communication occurs, where is the birthplace processing this datas?
In other words, I want to know whether these datas will be processed on CPU or brick.
Second, what is exact roles CPU and brick in bluethooth communication?
That means what is processed on CPU and what is processed on brick.
I have searched almost web site but I can't find this anywhere.
Please help me. Thanks.
You can see it in the package structure.
lejos.nxt.*
This package contains classes running on the NXT-brick. All code in this package will be compiled for the brick and will run on the brick.
lejos.pc.*
Here the difference is not that clear. This is java-code you compile for personal computer. So most code runs on your computer. But some classes (e.g: RemoteMotorController) only send messages to the NXT-brick which gives commands to the motors.
lejos.pc.comm provides API's that allow you to communicate/control the nxt robot from the PC.
When importing the the libs to an Android project, it allows you to build an instance of the same environment used on a pc, but within android.
I agree it can be tough finding some things out. It would be great if there was as stronger lejos presence on SO
This question is months old and has remained un-answered I actually have a lot of questions about it myself, but I might be able to provide some insight for utter novices.
when using bluetooth with Android and NXJ robots, you use either lejos.pc.comm or lejos.NXJ.
Both provide APi's to do almost the same thing, but work a little differently. I don't know nearly enough about the NXJ api, but I do know that it is the one that lets you manipulate the robot much more effectively, such as outputting data to it's LCD screen, which you can't do with the pc.comm api
As far as I can tell, the pc.comm API uses both Android Bluetooth API's and it's own protocols to allow communication with Lego LCP commands.
(I want to come back to this, but I'm writing a dissert on the topic so I'll try to update it in a couple of days. Seems not many are interested though, shame)
How to write simpliest audio virtual device driver in WinXP? I know that one way is to write a WDM driver but I suppose it is not an easyly task. I need to implement some audio filtering for a Flash based application. Unfortunatelly it seems that it is the only way to do it - outside a Flash, by a device driver, then a Flash app can attach to my virtual device.
I was wondering if I can write a device driver using some high level API (higher that WDM), maybe UMDF as virtual usb audio device(?) or maybe only some dll which will register a virtual device. As I can see Google Talk plugin contain googleadapter.dll which provfides virtual webcams, I wonder how they wrote it.
Thanks in advance,
ternyk
For WinXP it is enough to write Installable Driver which is a simple user-mode dll. However it will not work under Vista or higher because they have different audio model.
What API? First thing i'd worry about is learning how the app(s) interface with Windows and the best way to do this is to actually learn how to code an application with audio using the same interface. So, if it uses DirectSound audio, learn how to code an application which uses DirectSound.
The reason i say this is that once you know how your code works you will also know what API need to be hooked. Then it goes from there, code the loader/dll injector so that it performs what you're after.
Finally, don't forget to use Google to do as much research on your own first:
[quote]Give a man a fish, he'll eat for a day... Teach a man to fish and he'll never go hungry again...[/quote]
We have a range of PC demonstration programs for our microcontroller products. The programs typically connect to a USB HID chip on the microcontroller board. The USB chip acts as a communications bridge, allowing the programs to communicate with the micros over SPI/I2C/UART. The programs can configure the micros, and get back status information to display to the user.
We are now looking to build some standalone demonstrations using single board PCs. We would like to reuse as much as possible of our existing demo app source code. Ideally, we could just run them as-is.
Does anybody have any advice on the best way forward? The basic options seem to be WinCE or XP Embedded boards. WinCE boards seem to pull less power, which would be an advantage from a battery life point of view.
Our existing demos are built either in C++ under Borland Builder, or in Delphi.
Thanks in advance.
EDIT: see my answer below with info from a board vendor.
Free Pascal/Lazarus can compile some forms of Delphi apps to WiNCE/arm. Even visual ones.
There isn't a Delphi version for WinCE, so you would need to rewrite the applications. The same applies for the Borland Builder's control libraries. Only if you have used plain Win32 API, you would be able to port your application to WinCE easily. You may also encounter problems with the hardware access part. The Serial Port driver may not work as is. Also, you need to find a WinCE board that can act as USB host and provides HID drivers (this isn't very common).
In conclusion, I believe that you would be better of with Windows XP Embedded boards. These should run your applications as they are.
As an update, and for future reference, I thought I'd post the results of our discussions with a WinCE board vendor here. Caveat: I haven't actually tried any of this.
The bottom line is that there isn't a straightforward way to do what we were hoping for (i.e., re-compile our existing demo applications to run under WinCE). The reason is that the generic HID drivers and standard APIs that exist in desktop flavours of Windows just aren't there in WinCE.
To talk to HID devices in WinCE you need to implement a custom HID driver. This needs to support an interface allowing user mode applications to communicate with the driver, and to construct HID reports to be sent to the physical device. As this interface would itself be custom, application code needs to be updated accordingly.
WinCE application development is generally done using Visual Studio and the Microsoft compilers. The approach recommended to us was:
Create a custom HID class driver. This could be based on, for instance, the Microsoft keyboard HID driver.
Create an API for talking to the driver.
Use .net to create our GUI applications, and use PInvoke to actually talk to the API.
The end result of all this head-scratching is that to avoid the time and learning curve associated with this approach, we're going to go for a board running XP. We can then use our existing demo applications straight out of box. The trade-off is that we'll have to live with substantially reduced battery life.