> Have you notice BufferedByteCount property ?
Yes, I mentioned in my first message, but since it's undocumented (not
mentioned in the Wiki, FAQ or Help) it took me a while to understand how
the wsocket buffering works.
But in this case, TWSocket is poorly designed and network issues can
al
>>> I have also implemented a property called MaxSendBuffer
>>
>> I think this needs to go into TWSocket.
>
> Agreed.
I don't. See my response to Angus.
--
Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html
--
[EMAIL PROTECTED]
http://www.overbyte.be
--
To unsubscribe or
>> I have also implemented a property called MaxSendBuffer
>
> I think this needs to go into TWSocket.
The component doesn't know what to do if too much data is sent. It is the
application responsability to take any appropriate action: throw data away,
pause the data source, overflow the buffer
> The problem you are having is with you software CamCollect?
No, CamCollect just receives HTTP images and more rarely streams.
The video servers are for something completely different, a bespoke
application.
The application locking up under intense CPU stress is ComCap, just
moving multiple
> I have four 8-channel video servers in my office (but only 15 cameras)
> which offer different types of streaming, one if Linux based and streams
> HTTP, two are Windows based and use UDP, the last is an embedded system
> with hardware MPEG encoding on all channels and also streams eight
> channe
Angus Robertson - Magenta Systems Ltd wrote:
> I have four 8-channel video servers in my office (but only 15 cameras)
> which offer different types of streaming, one if Linux based and
> streams HTTP, two are Windows based and use UDP, the last is an
> embedded system with hardware MPEG encoding on
> but this is what I have concluded
> reading the source, because the send routine always put your data
> into internal buffer, growing it as data is incoming.
Agree.
> I have an Client / Server application for IP Camera Surveillance
> (www.digifort.com.br), and one feature of it works like t
> But you said in your case you cannot control the rate your
> random is arriving at (or did I misinterpret?) so what else can you
> do except keep buffering it, or error?
My main concern is to stop the application crashing, which has happened
three times this month, so I need to ignore new dat
> I have been working with ICS for some time and I had the same problem as
> you, I have read the ICS source code and I saw that it doesn´t have this
> flow control on send, what they have is the internal buffer where data is
> stored and sent in background, so, for example, if you have a 56kbps
>
>> Use event OnDataSent to control the flow, and to avoid grow of
>> TWSocket's send buffer.
> That is impossible for random data, unless an extra FIFO buffer is used
> externally to TWSocket.
I don't understand what you mean. You can use OnDataSent to fetch more data
to send.
> Trying to under
Hello,
I have developed something similiar to your needs on my application, I have
an HttpSrv that should send an internal stored JPEG to the clients over an
GET request to this JPEG, and it is working just fine, please check this
code, this should be implemented on CommandGET event (ICS 6) (Ac
Hello Angus,
I have been working with ICS for some time and I had the same problem as
you, I have read the ICS source code and I saw that it doesn´t have this
flow control on send, what they have is the internal buffer where data is
stored and sent in background, so, for example, if you have a
Partially correct. You don't need an extra FIFO buffer externally to
TWSocket because TWSockets buffers are FIFO buffers. You are right that
these will grow until you run out of memory if you cant send data as fast as
you receive it. But you said in your case you cannot control the rate your
ran
> Use event OnDataSent to control the flow, and to avoid grow of
> TWSocket's send buffer.
That is impossible for random data, unless an extra FIFO buffer is used
externally to TWSocket.
Trying to understand how TIcsBufferHandler works, it appears to be
multiple 1,460 byte blocks (TIcsBuffer
I don't know what is the cause of your problem, but I'm sure you should have
a look at AnswerStream method in the component.
--
Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html
--
[EMAIL PROTECTED]
http://www.overbyte.be
- Original Message -
From: "xmedia" <[EMAI
>> I don't understand what you want. Obviously you can't make a TCP
>> session running fatser than a TCP session !
>
> But I can supply data faster than the session can support. The data
> might be coming from another application and I'm sending it over a slow
> modem, so there must be flow contro
>>> (1) Not reply to the client until after 10 seconds (using a TTimer?).
>>> You
>>> don't have to sleep. I'm sure the HTTP server has some kind of delayed
>>> reply mechanism.
>>>
>>
>> Yes, you can reply later. Use hgSendMySelf
> Does it work like this?
>
> In my OnGetDocument I set Flags to h
>> (1) Not reply to the client until after 10 seconds (using a TTimer?).
>> You
>> don't have to sleep. I'm sure the HTTP server has some kind of delayed
>> reply mechanism. You can put the client in a 'waiting' list and only
>> send
>> the reply after your timeout.
>>
> That would be plain sim
Angus Robertson - Magenta Systems Ltd wrote:
>> I don't understand what you want. Obviously you can't make a TCP
>> session running fatser than a TCP session !
>
> But I can supply data faster than the session can support. The data
> might be coming from another application and I'm sending it ove
Hello!
I am trying to send a JPEG stream stored in memory to HttpCli. Below is my
code. It worked well for first few days and then the server (I mean the
HttpSvr , not the application) just stopped responding to any http request
until I restart the application.
The cause seems to be related to se
20 matches
Mail list logo
