Francois PIETTE wrote:
>
> IMO, you have all the required tools !
Yes, no question, you realy have all the required tools. But you
also have the required tools to write a SMTP client using TWSocket,
and nevertheless there's a SMTP client in ICS. What I mean is that
it won't hurt to put that in, b
efore calling Send !
--
[EMAIL PROTECTED]
http://www.overbyte.be
- Original Message -
From: "Angus Robertson - Magenta Systems Ltd" <[EMAIL PROTECTED]>
To:
Sent: Monday, November 20, 2006 2:02 AM
Subject: Re: [twsocket] Flow control
> > Have you notice BufferedByte
Hello Francois,
> IMO, you have all the required tools !
Agree for 100% !
Definitively no need to put wishels and bells into TWSocket !
All the tools are there, this is up to derrived components and or
applications.
---
Rgds, Wilfried [TeamICS]
http://www.overbyte.be/eng/overbyte/teamics.html
ht
> 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
re CamCollect?
Did you figured out how to solve it?
Éric
- Original Message -
From: "Angus Robertson - Magenta Systems Ltd" <[EMAIL PROTECTED]>
To:
Sent: Sunday, November 19, 2006 2:13 PM
Subject: Re: [twsocket] Flow control
>> but this is what I have concluded
&g
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
ng, to make this flow control.
Ps. My data is also random...
Hope I could help you
Éric Fleming Bonilha
Digifort
- Original Message -
From: "Angus Robertson - Magenta Systems Ltd" <[EMAIL PROTECTED]>
To:
Sent: Sunday, November 19, 2006 8:22 AM
Subject: Re: [twsocket]
Sent: 19 November 2006 11:22
To: twsocket@elists.org
Subject: Re: [twsocket] Flow control
> 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.
Tryi
> 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 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
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
> 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 control som
> If I'm trying to send random data at a speed faster than a TCP socket
> can support,
I don't understand what you want. Obviously you can't make a TCP session
running fatser than a TCP session ! You can make it run slower but not
faster !
Or maybe you want to use UDP which is faster than TCP b
If I'm trying to send random data at a speed faster than a TCP socket
can support, what errors should I expect from TWSocket.Send? This might
be a slow connection, or a remote that can not process the stream fast
enough.
I can not see any error handling in the send buffering code to reject
21 matches
Mail list logo
