calling Send !
--
[EMAIL PROTECTED]
http://www.overbyte.be
- Original Message -
From: Angus Robertson - Magenta Systems Ltd [EMAIL PROTECTED]
To: twsocket@elists.org
Sent: Monday, November 20, 2006 2:02 AM
Subject: Re: [twsocket] Flow control
Have you notice BufferedByteCount property
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,
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 over a
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
, 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: twsocket@elists.org
Sent: Sunday, November 19, 2006 8:22 AM
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.
I don't understand what you mean. You can use OnDataSent to fetch more data
to send.
Trying to understand
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
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 data
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 this,
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
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 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 to
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 change
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
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
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
16 matches
Mail list logo
