date:20110127

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 dealing with properties BandwidthLimit & BandwidthSampling to 
corresponding methods of FtpCli based in OverbyteIcsHttpProt.pas. Then find 
TCustomFtpCli.DataSocketGetInit and copypaste {$IFDEF 
BUILTIN_THROTTLE}...{$ENDIF} block into THttpCli.DoBeforeConnect (you'll also 
need to add httpoBandwidthControl to THttpCliOption type - it'll be replacement 
of ftpBandwidthControl option). And as long as I understand, you're done.

2Angus:
>Anton was not referring to the HTTP client, but the FTP client.  He was
>asking for some code to be simplified, but the code he posted is actually
>obsolete and no longer used by the FTP client.  

>It has been replaced by new common throttling code in TWSocket which is
>enabled by the BUILTIN_THROTTLE definition.  This was only added last
>year, so we tend to keep old code for a while until new code is
>thoroughly tested.  
Well, my report of repeating code pieces has little connection with the topic, 
moreover, I guess it's only Arno and/or Francois who might be interested in my 
report. But as we are talking about bandwidth stuff I decided to mention it 
inside this topic.
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.

-- 
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

[twsocket] Using the FTP Client

 
OK all you clever people out there this is my current problem.

I have an application that connects to a newsroom computer system (NCS) via
FTP. I have a server in my office and use the ICS FTP client to make the
connection. LIST commands, RETR commands etc. are going on pretty well all
the time. In addition to this, the application is sending and receiving data
via USB to some proprietary hardware. With my simple network which just
consists of a few computers on a Workgroup, every thing is perfect. FTP data
is loading to the application and USB data is flying back and forth.

However at the customers site (big TV news station), all changes. The
symptom I get is that when I turn on the FTP and start getting data, somehow
the application can at times no longer get data from the USB quick enough. I
found that I was sending more data up the USB than was necessary and when
this was fixed the system at the customers site worked perfectly.

Now the bad news. The customer needs proof that it is the FTP or something
to do with the network that is causing the problem. Somehow I need to be
able to replicate his problem on my system. I have tried playing with the
ftpBandwidthControl and the BandwidthLimit, but cannot seem to make it do
much. The customer suggested I should be able to throttle the data. Is this
the same thing or something else I can try.

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?

Any help much appreciated.

Graham

--
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

Re: [twsocket] HttpCli, bandWidthLimit ?

2011-01-27 Thread Bruno Mannina

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 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 dealing with properties BandwidthLimit& BandwidthSampling to corresponding methods
of FtpCli based in OverbyteIcsHttpProt.pas. Then find TCustomFtpCli.DataSocketGetInit and
copypaste {$IFDEF BUILTIN_THROTTLE}...{$ENDIF} block into THttpCli.DoBeforeConnect (you'll
also need to add httpoBandwidthControl to THttpCliOption type - it'll be replacement of
ftpBandwidthControl option). And as long as I understand, you're done.

2Angus:

Anton was not referring to the HTTP client, but the FTP client. He was
asking for some code to be simplified, but the code he posted is actually
obsolete and no longer used by the FTP client.
It has been replaced by new common throttling code in TWSocket which is
enabled by the BUILTIN_THROTTLE definition. This was only added last
year, so we tend to keep old code for a while until new code is
thoroughly tested.

Well, my report of repeating code pieces has little connection with the topic,
moreover, I guess it's only Arno and/or Francois who might be interested in my
report. But as we are talking about bandwidth stuff I decided to mention it
inside this topic.
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.

--
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

Re: [twsocket] Using the FTP Client

>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
--
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

Re: [twsocket] Using the FTP Client

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
To: twsocket@elists.org
Subject: Re: [twsocket] Using the FTP Client

>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
--
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

--
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

Re: [twsocket] Using the FTP Client

2011-01-27 Thread Angus Robertson - Magenta Systems Ltd

> 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 error
the USB memory key is causing, Windows will be upset. 

> 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?

No, FTP uses very little CPU.  I was testing the new bandwidth throttling
a few months ago, with both ICS FTP client and server, and using one
thread per FTP client I was successfully running 250 simultaneous FTP
sessions (using my TMagFtp component), that is proper sessions each
indexing files and downloading multiple real files at the same time.  I
even had 100 session to my public FTP server over the internet. 

Durations did increase as number of sessions went up, but never stopped,
and that was on my old Core2 PC with 32-bit Windows and little memory, my
newer PC is much more beefy and it's all 64-bit now, but not had time to
test again. 

Angus
 

--
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

Re: [twsocket] HttpCli, bandWidthLimit ?

2011-01-27 Thread Angus Robertson - Magenta Systems Ltd

> 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 applications.  But there is no point in
rewriting it which is what you were suggesting. 

Angus

--
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

Re: [twsocket] Using the FTP Client

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 the
FTP data is being processed, the USB is continually monitored and FTP
processing is interrupted to service the USB. All this works on my system
and I just need some ideas as to what can cause this at the customer site.
>From what you say, you are ruling out the FTP client itself. I shall try and
get some ICS logging files to compare.

Graham

-Original Message-
From: twsocket-boun...@elists.org [mailto:twsocket-boun...@elists.org] On
Behalf Of Angus Robertson - Magenta Systems Ltd
Sent: 27 January 2011 14:31
To: twsocket@elists.org
Subject: Re: [twsocket] Using the FTP Client

> 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 error the USB
memory key is causing, Windows will be upset. 

> 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?

No, FTP uses very little CPU.  I was testing the new bandwidth throttling a
few months ago, with both ICS FTP client and server, and using one thread
per FTP client I was successfully running 250 simultaneous FTP sessions
(using my TMagFtp component), that is proper sessions each indexing files
and downloading multiple real files at the same time.  I even had 100
session to my public FTP server over the internet. 

Durations did increase as number of sessions went up, but never stopped, and
that was on my old Core2 PC with 32-bit Windows and little memory, my newer
PC is much more beefy and it's all 64-bit now, but not had time to test
again. 

Angus
 

--
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

--
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

Re: [twsocket] Using the FTP Client

2011-01-27 Thread Angus Robertson - Magenta Systems Ltd

> 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 file and not trying to immediately resend the
data to USB?  

It may be the USB stuff needs 100% CPU and can not tolerate anything else
running.  You are using async FTP, or at least FTP in a thread which is
how I got 250 sessions running?  

You really just need to keep Task Manager running while the problem is
happening, and see how many seconds of CPU each different application is
using, the hog should become obvious. 

> All this works on my system

So you have the teleprompter for development testing?  It is often hard
to replicate customer environments.   

Angus

--
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

Re: [twsocket] TWSocketServer and TWSocket Port




It's easy to implement encryption but you'll have to add key exchange also and 
exclude possibility of key sniffing what is quite harder.


Just start with a fixed strong password, and add to it a variable salt 
that can be a hash of some of the client/server header fields. One of 
this fields could be the local time, that will be used by the 
Client/Server to select what method to use in the construction of the 
value to hash, such as if this time is odd or even, etc.. Use this 
password+salt to encrypt the data.

Here you have a simple key exchange, that will not be easy to break.
--
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

Re: [twsocket] HttpCli, bandWidthLimit ?

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 default so "old code" is still in use. Moreover, as these 
features require an additional thread there certainly could be some people who 
won't like an idea of turning their apps to multi-threaded ones.

-- 
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

Re: [twsocket] Another unicode issue

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 OverbyteIcsHttpSrv.pas and 
OverbyteIcsHttpAppServer.pas here:
http://www.duodata.de/misc/delphi/ics/OverbyteIcsHttpSrv733.zip 

Fixed VarRecToString. AnswerPage and other functions take 
optional codepage parameters now, you asked that some days back.
So it should now be possible to write i.e. UTF-8 encoded HTML
by passing CP_UTF8 in parameter DstCodePage, the default is
CP_ACP. Since it's not much tested please give it a trial and 
let me know how it works for you before I upload this change to
the repository.

-- 
Arno Garrels  
--
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

Re: [twsocket] TWSocketServer and TWSocket Port

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 intercepted data maintaining its validity, if he can't
> break the encrypt algorithm in time to inject his packets of data.

With a stolen key that's easy.

> This is also valid for SSL.

No, the difference is that SSL is able to detect the man in the middle.
Usually the certificate includes some information like the domain
name or IP address, so even if the attacker used a stolen certificate
peer verification would fail and the connection won't be established.

> 
>>> Closed standards are inheritable much more secure than
>>> open standards.
>> That's nothing but security through obscurity:
>> http://en.wikipedia.org/wiki/Security_through_obscurity
> 
> That's just a theoretic argument, not an undoubted reality.

There are enough examples mentioned in that wiki article to prove
the opposite.
 
> 
>>> In this type of projects the use of the of this
>>> standard is wrong. He just don't need the SSL implementation
>>> complexity, nor the result slow to start communication, just to get
>>> his data secure.
>> I don't know what _he needs, if _you want to invent your own security
>> standards feel free to do so. SSL/TLS is used and accepted
>> world-wide. 
> 
> Neither do I, but I'm assuming he only need what a generic data
> communication service needs in terms of security. Pass data in a way
> it can't be tampered/understood, if intercepted by someone outside the
> communication points.
> 
> I'm not replying to you, Arno, to be impertinent. Far from that. It's
> just my opinion that a symmetric keyed algorithm, such as AES or
> Blowfish, with a clever time volatile salt added to the key, is enough
> for this case in particular.

The weak point here is key delivery. Keys should be changed very 
frequently. How do you make sure that keys are not stolen and 
received by the right people? They should never be hard coded in the
application. SSL negotiates a unique symmetric key per session, so even
if the key was found by brute force it can be used only to decrypt a
single SSL session.

-- 
Arno Garrels




--
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

Re: [twsocket] Using the FTP Client

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

Re: [twsocket] HttpCli, bandWidthLimit ?

2011-01-27 Thread Angus Robertson - Magenta Systems Ltd

> 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, and the old TTimer used a thread
anyway, so nothing extra.  And there is only one TIcsThreadTimer for all
ICS components, instead of one thread for each separate TTImer, so lots
of potential savings. 

At least I assume Windows timers use a thread, not really any other way
they could run. 

Angus

--
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

Re: [twsocket] Using the FTP Client

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 better than
using PostMessage to basically generate an event into the main application
thread. I now have a background timer in the main thread which monitors the
incoming USB data string and if there is any FTP stream data to be
processed.

We write the software and manufacture the teleprompter hardware. I also have
my own iNEWS server.

Graham

-Original Message-
From: twsocket-boun...@elists.org [mailto:twsocket-boun...@elists.org] On
Behalf Of Angus Robertson - Magenta Systems Ltd
Sent: 27 January 2011 16:16
To: twsocket@elists.org
Subject: Re: [twsocket] Using the FTP Client

> 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 file and not trying to immediately resend the
data to USB?  

It may be the USB stuff needs 100% CPU and can not tolerate anything else
running.  You are using async FTP, or at least FTP in a thread which is how
I got 250 sessions running?  

You really just need to keep Task Manager running while the problem is
happening, and see how many seconds of CPU each different application is
using, the hog should become obvious. 

> All this works on my system

So you have the teleprompter for development testing?  It is often hard
to replicate customer environments.   

Angus

--
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

--
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

Re: [twsocket] HttpCli, bandWidthLimit ?

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 defines commented by default so "old code" is still
> in use. 

True, however simply build the FtpTst demo with "BUILTIN_THROTTLE" 
defined in the project options and see the new code in action.  

> Moreover, as these features require an additional thread
> there certainly could be some people who won't like an idea of
> turning their apps to multi-threaded ones.

Any ICS application is multi-threaded, winsock creates at least
one additional thread with async sockets. However the additional
thread of the new throttle is not per instance, many throttled
TWSocket instances just use a single thread.

-- 
Arno Garrels
--
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

Re: [twsocket] TWSocketServer and TWSocket Port





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 components, just because you want your data 
exchange to have some kind of protection in the final implementation, is 
wrong.
Start it simple, and increase the complexity after you are comfortable 
with what you have already.




For me the mosty important here is to learn one thing at a time.


So, leave SSL apart for now.



If I listen you,
I have to start learning something else also. Your way of handling is 
not going to help me to understand the ICS sockets better it will make 
things more complicated and difficult.


Where I said that. It's exactly the contrary. You are the one that 
insist in the usage of a complex component from the start.




A question,
Would you help me with few code examples if I do exactly what you are 
saying?


You have all you need to start in the ICS standard samples, and Francois 
and others already pointed you to the correct ones, and even gave you 
code examples to specific questions, but you continue asking the same 
questions, over and over again. My feel is that your knowledge of the 
Delphi language itself is very limited,  and this is not the right place 
to learn it.



If you really want to help me,
Post me few examples (don't explain) of how to?
- Send command to the client socket by using it's computer name


It was been explained to you already, more than one time.


- Recieve WMI information from the client socket ==> I am not asking 
you to help with WMI, I can do it myself, all I need is how to connect 
to WMI from server socket to the client socket and receive the data.


 Already explained too. Use the ongoing client to server connection to 
send data to the client.


- How to handle the errors of sockets (example: if client loses the 
connection it gives error in the window, how this can be handled in 
the sockets).


Just ask this directly in the list. I'm not an expert in the subject.

--
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

Re: [twsocket] HttpCli, bandWidthLimit ?

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 http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be

Re: [twsocket] TWSocketServer and TWSocket Port





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, the difference is that SSL is able to detect the man in the middle.
Usually the certificate includes some information like the domain
name or IP address, so even if the attacker used a stolen certificate
peer verification would fail and the connection won't be established.



Man in the middle attacks intercepts data in a transparent way, in the 
"middle of the line" and in a ongoing communication . The "in the 
middle" IP address is not even a variable for the peer verification.




I'm not replying to you, Arno, to be impertinent. Far from that. It's
just my opinion that a symmetric keyed algorithm, such as AES or
Blowfish, with a clever time volatile salt added to the key, is enough
for this case in particular.

The weak point here is key delivery. Keys should be changed very
frequently. How do you make sure that keys are not stolen and
received by the right people? They should never be hard coded in the
application. SSL negotiates a unique symmetric key per session, so even
if the key was found by brute force it can be used only to decrypt a
single SSL session.


True, but you can also have you own key exchange method too.
And you would reply, so why not use the already available SSL protocol 
that do exactly that?
Because everyone know how it works, and if I'm going to develop my 
Client and Server, I don't need to use something that is public available.



--
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

Re: [twsocket] Using the FTP Client

2011-01-27 Thread Angus Robertson - Magenta Systems Ltd

> 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 issues. 

> We write the software and manufacture the teleprompter hardware. I 
> also have my own iNEWS server.

Absolutely the best way to test it all!

Angus

--
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

Re: [twsocket] TWSocketServer and TWSocket Port

2011-01-27 Thread daniel cc


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 for me as Arno also has convinced me about it.
If I can figure out few things than I will have no problems of doing my 
project to the end because I am already very close to it.


My feel is that your knowledge of the
Delphi language itself is very limited,  and this is not the right place
to learn it.


This is something which isn't easy to tell about what is the limited 
knowledge.
Every programmer is good in some fields and the network communication is not 
mine.


It was been explained to you already, more than one time.



You probably have which I haven't understand i bit of it.
Explaining is one thing and understanding is another.
And expecting that everything is as simple as you have explained and 
expecting that the person is capable of understanding exactly what you are 
saying is also another thing.


Everything will work perfectly when you guys stop treating me as a guru and 
try to give me samples of what can be done and how it can be used.

Please MARK ON THIS!!
I am not asking anyone to write code for me, I can do that myself.
All I am asking is explain it with a sample of what can be  done and how can 
be done, guide me to the samples, guide me to the direction.
I am most of the time getting one explanation and 4 different directions 
such as yours telling me to use something else than what I am trying to do.


And.
Please let's quit this here and continue to some other subjects. 


--
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

Re: [twsocket] Another unicode issue

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 versions of OverbyteIcsHttpSrv.pas and
> OverbyteIcsHttpAppServer.pas here:
> http://www.duodata.de/misc/delphi/ics/OverbyteIcsHttpSrv733.zip
> 
> Fixed VarRecToString. AnswerPage and other functions take
> optional codepage parameters now, you asked that some days back.
> So it should now be possible to write i.e. UTF-8 encoded HTML
> by passing CP_UTF8 in parameter DstCodePage, the default is
> CP_ACP. Since it's not much tested please give it a trial and
> let me know how it works for you before I upload this change to
> the repository.

Just in case you downloaded the wrong ZIP, VarRecToString should
look like:

function VarRecToString(V : TVarRec) : String;
const
BooleanToString : array [Boolean] of String = ('FALSE', 'TRUE');
begin
case V.VType of
vtInteger:Result := _IntToStr(V.VInteger);
vtBoolean:Result := BooleanToString[V.VBoolean];
vtChar:   Result := String(V.VChar);
vtExtended:   Result := _FloatToStr(V.VExtended^);
vtString: Result := String(V.VString^);
vtPointer:Result := 'Unsupported TVarRec.VType = vtPointer';
vtPChar:  Result := String(_StrPas(V.VPChar));
vtObject: Result := 'Unsupported TVarRec.VType = vtObject';
vtClass:  Result := 'Unsupported TVarRec.VType = vtClass';
vtWideChar:   Result := String(V.VWideChar);
vtPWideChar:  Result := String(V.VPWideChar);
vtAnsiString: Result := String(_StrPas(V.VPChar));
vtCurrency:   Result := 'Unsupported TVarRec.VType = vtCurrency';
vtVariant:Result := 'Unsupported TVarRec.VType = vtVariant';
vtWideString: Result := 'Unsupported TVarRec.VType = vtWideString';
vtInterface:  Result := 'Unsupported TVarRec.VType = vtInterface';
vtInt64:  Result := _IntToStr(V.VInt64^);
{$IFDEF COMPILER12_UP}
vtUnicodeString:  Result := PWideChar(V.VUnicodeString);
{$ENDIF}
else
Result := 'Unknown TVarRec.VType = "' + _IntToStr(Ord(V.VType)) + '" ';
end;

//OutputDebugString(PChar('VarRecToString ' + Result));
end;
--
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

Re: [twsocket] TWSocketServer and TWSocket Port

2011-01-27 Thread daniel cc

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 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 for me as Arno also has convinced me about it.
If I can figure out few things than I will have no problems of doing my
project to the end because I am already very close to it.

My feel is that your knowledge of the
Delphi language itself is very limited,  and this is not the right place
to learn it.

This is something which isn't easy to tell about what is the limited
knowledge.
Every programmer is good in some fields and the network communication is not
mine.

It was been explained to you already, more than one time.

You probably have which I haven't understand i bit of it.
Explaining is one thing and understanding is another.
And expecting that everything is as simple as you have explained and
expecting that the person is capable of understanding exactly what you are
saying is also another thing.

Everything will work perfectly when you guys stop treating me as a guru and
try to give me samples of what can be done and how it can be used.
Please MARK ON THIS!!
I am not asking anyone to write code for me, I can do that myself.
All I am asking is explain it with a sample of what can be  done and how can
be done, guide me to the samples, guide me to the direction.
I am most of the time getting one explanation and 4 different directions
such as yours telling me to use something else than what I am trying to do.

And.
Please let's quit this here and continue to some other subjects.

--
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 

--
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

[twsocket] Error handling

2011-01-27 Thread daniel cc

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 I wouldn’t like to see.
I would like to handle the errors into the log file and read them if needed.
Please notice,
I don’t need help for putting errors into the log file, I just need to know 
about how the errors are handled best in the socket components.

Thanks in advance
--
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

Re: [twsocket] TWSocketServer and TWSocket Port

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 SSL.
>> No, the difference is that SSL is able to detect the man in the
>> middle. Usually the certificate includes some information like the
>> domain 
>> name or IP address, so even if the attacker used a stolen certificate
>> peer verification would fail and the connection won't be established.
> 
> 
> Man in the middle attacks intercepts data in a transparent way, in the
> "middle of the line" and in a ongoing communication . The "in the
> middle" IP address is not even a variable for the peer verification.

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), acting as a proxy server.

> 
>>> 
>>> I'm not replying to you, Arno, to be impertinent. Far from that.
>>> It's just my opinion that a symmetric keyed algorithm, such as AES
>>> or Blowfish, with a clever time volatile salt added to the key, is
>>> enough for this case in particular.
>> The weak point here is key delivery. Keys should be changed very
>> frequently. How do you make sure that keys are not stolen and
>> received by the right people? They should never be hard coded in the
>> application. SSL negotiates a unique symmetric key per session, so
>> even if the key was found by brute force it can be used only to
>> decrypt a single SSL session.
> 
> True, but you can also have you own key exchange method too.
> And you would reply, so why not use the already available SSL protocol
> that do exactly that?

Exactly.

> Because everyone know how it works, 

That's the point, bugs in proprietary protocols are usually not found as
fast as bugs in public protocols (by the good guys).

> and if I'm going to develop my
> Client and Server, I don't need to use something that is public
> available. 

Of course you can, I just doubt that it's more secure than properly 
implemented SSL/TLS.

-- 
Arno Garrels 
--
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

Re: [twsocket] TWSocketServer and TWSocket Port


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), acting as a proxy server.


But stolen keys is your previous argument. After you have it, decoding 
the data is much more easy if you know how the key is used to 
encrypt/decrypt it.
Knowing the encrypt algorithm is also important to, with brute-force, 
decode the data, if you just want to see what the communication is all 
about. That's why the security agencies don't like closed protocols.


--
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

Re: [twsocket] sending jpg through httpserver

2011-01-27 Thread Edwin @ Clanhay

That did the trick.
Thanks Peter for the quick response.

Ed

- Original Message - 
From: "Busai Péter" 

To: "ICS support mailing" 
Sent: Wednesday, January 26, 2011 5:25 PM
Subject: Re: [twsocket] sending jpg through httpserver

Hi Edwin,

AnswerStream is just perfect for that.
Here is how I send png. It is stored in FpngStream, which is also a
TMemoryStream.
I dont want it to be destroyed after sent. That is why I create an other
memory stream and copy
then content.

ClientCnx.DocStream := TMemoryStream.Create;
ClientCnx.DocStream.CopyFrom(TSessionData(SessionList[index]).FpngStream,0);
ClientCnx.AnswerStream(Flags,'','image/png','');

Peter

2011.01.26. 22:53 keltezéssel, Edwin @ Clanhay írta:
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.

Any ideas?

ed

--
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

--
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

Re: [twsocket] TWSocketServer and TWSocket Port