Dear Anton,
Thank you for your message,
Unfortunately my programmation level is not engouh good to understand
your explanation and
therefore I am unable to make any modifications you to tell me,
I do not even know what file I need to change :'(
Could you guide me to do the modification please
Unfortunately my programmation level is not engouh good to
understand your explanation and
therefore I am unable to make any modifications you to tell me,
I do not even know what file I need to change :'(
Anton was not referring to the HTTP client, but the FTP client. He was
asking for some
2Bruno:
Could you guide me to do the modification please ? and where ?
it would be really nice from you.
Well, I'm not an expert in ICS and have little knowledge of HttpCli but here's
dummy vision of the issue.
Search inside OverbyteIcsFtpCli.pas for BUILTIN_THROTTLE and copy-paste all
the stuff
Dear Anton,
Thanks a lot for these information, I will do the tests and modification
tonight at home.
I will keep inform if I success to do it.
Thx a lot !
Bruno
Le 27/01/2011 13:28, Anton S. a écrit :
2Bruno:
Could you guide me to do the modification please ? and where ?
it would be
Is it possible that the FTP transactions can, for whatever network reasons,
hog the CPU resources so that my application cannot get access to the USB
data?
Is it possible to completely turn off all FTP exchanges and try only with USB?
You may also check CPU usage during FTP sessions.
--
Anton
With FTP off or connected but not receiving data then all is fine. No
problem with USB.
Haven't looked at CPU usage, will possibly try that.
Graham
-Original Message-
From: twsocket-boun...@elists.org [mailto:twsocket-boun...@elists.org] On
Behalf Of Anton S.
Sent: 27 January 2011 13:24
somehow the application can at times no longer get data from the USB
quick enough.
Disk I/O in Windows can be blocking, you normally only see it with bad
disk sectors when the event log shows lots of errors in red when it times
out waiting for a response from the drive. If this is the sort of
As long as obsoleteness is concerned, I have no info on future
plans of this feature but the ICS NOT BREAK EXISTING CODE
commandment hints that UseBandwidthControl would probably remain.
The old bandwith control code is unused, indeed not compiled, so removing
it does not break existing
The USB device is not a disk drive, but a teleprompter. Data is sent when
requested from the device. So single bytes from the device result in large
amounts of data being sent from the PC to the USB device. All this works. It
is only when the FTP is getting data that it can go pear shaped. While
It is only when the FTP is getting data that it can go pear shaped.
While the FTP data is being processed, the USB is continually
monitored and FTP processing is interrupted to service the USB.
Are FTP and USB servicing running as separate applications? FTP is
presumably writing a simple
2Angus
The old bandwith control code is unused, indeed not compiled, so removing
it does not break existing applications. But there is no point in
rewriting it which is what you were suggesting.
I don't think so. OverbyteIcsDefs.inc has BUILTIN_TIMEOUT BUILTIN_THROTTLE
defines commented by
Busai Péter wrote:
In HttpAppServer, URLHandler
Call
Client.AnswerPage(Flags,'','','template.html',nil,['SOMEKEY','A']);
The value of SOMEKEY must be one character long.
Result rendered in html page:
Unsupported TVarRec.VType = vtWideChar
I uploaded changed versions of
RTT wrote:
Man in the Middle attacks don't work if the man in the middle
don't know how to handle the encrypted data/protocol he is
intercepting.
True, and how do you manage that is not happening?
Can't be happening because the man in the middle can't generate valid
data, or alter
Maybe you'd try to extract USB interaction into separate thread and assign to
it a higher priority?
--
Anton
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
I don't think so. OverbyteIcsDefs.inc has BUILTIN_TIMEOUT
BUILTIN_THROTTLE defines commented by default so old code is
still in use.
Only until I finish testing and remove the old stuff.
Moreover, as these features require an additional thread
Only one thread to run TIcsThreadTimer,
It is all one application. The FTP client uses only Async commands and loads
the data to a stream. The USB component, based on CreateFile etc. has a high
priority thread for reading data and stores the data in a string embedded in
a Critical Section Acquire and Release. In this instance this is
Anton S. wrote:
2Angus
The old bandwith control code is unused, indeed not compiled, so
removing it does not break existing applications. But there is no
point in rewriting it which is what you were suggesting.
I don't think so. OverbyteIcsDefs.inc has BUILTIN_TIMEOUT
BUILTIN_THROTTLE
It is a very simple monitoring system.
SSL is okay for this as far as I am concerned.
As others have say to you already, just concentrate your efforts in the
development of the client and server code. Leave the data encryption to
the last stage of the project.
Starting with the SSL
Angus, Arno, thanks for info about threads in ICS! I'll probably take a look at
built-in timeouts and use them instead of my own ones which I implemented by
TIcsTimer.
--
Anton
--
To unsubscribe or change your settings for TWSocket mailing list
please goto
With a stolen key that's easy.
Sure, and this is exactly what SSL try to circumvent.
But not so easy if the encrypt key is not a fixed value, but a variable
one. The attacker will need to stole the client or server code and
reverse engineering it too.
This is also valid for SSL.
No,
It is all one application.
While having one application is very convenient, is there not some way to
decouple the two different tasks into separate applications, perhaps with
a socket being used for communication, or maybe just shared memory? This
would remove any possible thread synchronise
So, leave SSL apart for now.
I don't see any reasons to leave the SSL because I already spent 3 weeks
with making lot of tests and have learned much about SSL and I will
continue.
I am also hoping that you guys try to understand my approach instead of
asking to leave it.
SSL is good enough
Arno Garrels wrote:
Busai Péter wrote:
In HttpAppServer, URLHandler
Call
Client.AnswerPage(Flags,'','','template.html',nil,['SOMEKEY','A']);
The value of SOMEKEY must be one character long.
Result rendered in html page:
Unsupported TVarRec.VType = vtWideChar
I uploaded changed
SOLVED!!
-Original Message-
From: daniel cc
Sent: Thursday, January 27, 2011 7:33 PM
To: ICS support mailing
Subject: Re: [twsocket] TWSocketServer and TWSocket Port
So, leave SSL apart for now.
I don't see any reasons to leave the SSL because I already spent 3 weeks
with making
Hello,
Can someone please guide me to a demo where the ICS Socket errors are handled?
I have checked almost all and each one of them are having some handling but I
can’t get the result I need.
Example: If I pull the network cable from the client I get socket error pop-up
which is something that
RTT wrote:
With a stolen key that's easy.
Sure, and this is exactly what SSL try to circumvent.
But not so easy if the encrypt key is not a fixed value, but a
variable one. The attacker will need to stole the client or server
code and reverse engineering it too.
This is also valid for
On 27-01-2011 18:27, Arno Garrels wrote:
Without the certificate(s) and private key(s) he may intercept transparently
as long as he likes. When he wants to decrypt the session on the fly he
has to go thru the handshake process on behave of the victim by presenting
the stolen certificate(s),
That did the trick.
Thanks Peter for the quick response.
Ed
- Original Message -
From: Busai Péter busai...@t-online.hu
To: ICS support mailing twsocket@elists.org
Sent: Wednesday, January 26, 2011 5:25 PM
Subject: Re: [twsocket] sending jpg through httpserver
Hi Edwin,
RTT wrote:
That's why the security agencies don't like closed protocols.
Nobody knows whether a proprietary security protocol has some
built-in universal key, given i.e. to a security agency.
That's also why users should not rely on proprietary security
protocols and cryptographic algorithms.
Hi Arno,
There were two DestCodePage parameter passover missing in
OverbyteIcsHttpSrv.
function HtmlPageProducerFromMemory
Line: 5068
HandleTableRow(TagParams, P + J + 1, Q - P - J - 1,
RowDataGetter, UserData, DestStream,
DestCodePage);
and
Line: 5076
I am trying to send a jpg from delphi's tjpgImage to a client with the
tHTTPServer component.
Would like to keep it in a memory stream and not save to disk, but
AnswerStream is not what it sounds like.
Searched the archives but found little that was close to what I wanted.
Still using ICS 5.
While the FTP data is being processed, the USB is continually monitored
and FTP processing is interrupted to service the USB.
Reading that rings the bell in my head !
If you are using polling, then this is bad design.
Use two separate threads to handle USB and to handle FTP. Each thread should
Can someone please guide me to a demo where the ICS Socket errors are
handled?
I have checked almost all and each one of them are having some handling
but I can’t get the result I need.
Example: If I pull the network cable from the client I get socket error
pop-up
which is something that I
33 matches
Mail list logo
