Re: [twsocket] Flow control
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 slow modem, so there must be flow control somewhere when the TCP buffers overflow. But I can not find it. Send does not currently appear to check data has previously been sent and there is space in the buffer. TWSocket has a built-in, dynamic send buffer, that's why calling TWSocket.Send always succeeds, real sending is done in the background. The component handles winsock buffer overflows (WSAEWOULDBLOCK)internaly. Use event OnDataSent to control the flow, and to avoid grow of TWSocket's send buffer. --- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Multi-Threaded THttpServer?
(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 simply perfect for what i need but how do I do that? In OnGetDocument you have a Flags argument which tells the component what it has to do after the event is done. If you set it to hgWillSendMySelf, the component will do nothing to send any reply. You can then send it later. You have argument Client in OnGetDocument which tells you who made the request and has to receive the reply you build. You send the reply by invoking one of the AnswerXYZ method on the Client instance. It is interesting for you to run WebServ demo program under the debugger and place a breakpoint in OnGetDocument event handler, the follow the execution for a request such as time.html. You'll understand how the component works and you'll better use it. For the moment I only know how to use the OnGetDocument to generate the response and it doesn't provide any room for delaying it's processing! At what point in time, or where from can I put a request on hold so it doesn't get processed normally? You simply don't send anything from OnGetDocument (that is do not call AnswerXYZ method or Send or similar). You can call it later, for example from an OnTimer event. Please note I need to have at least part of the processing go normally, so I actually know it's a valid HTTP request and I know what document the user is requesting etc. If you come into OnGetDocument, then you have all the details available. If you search in the mailing list archive for answer defering you could find some more discussions. There is a link to the searcble archive in the support page at http://www.overbyte.be -- Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html -- [EMAIL PROTECTED] http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Multi-Threaded THttpServer?
(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 hgWillSendMySelf and then use the client component's send method do send() the data, then use it's Shutdown() method to gracefully close the connection and let the other side know I've finished sending? Or is there something more to this, like taking into account Keep Alive connections? Do not close the connection. Just send the answer, preferably using AnswerXYZ method. But anything else is OK provided you understand how to do it properly. Have a look at AnswerPage, AnswerStream or AnswerString if you want to write your own reply send function (I don't see any reason to write your own). -- Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html -- [EMAIL PROTECTED] http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Flow control
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 somewhere when the TCP buffers overflow. But I can not find it. This flow control is built into the TCP protocol. You don't have to do anything to handle it. TWSocket will buffer your data automatically. If you don't want to fill memory with lots of data, use OnDataSent event to get more data. OnDataSent is triggered each time TWSocket has emptyed his buffer. FTP component use OnDataSent event top read more data from the file to send. Send does not currently appear to check data has previously been sent and there is space in the buffer. Send put data into TWSocket internal buffer. Data is removed from that buffer when winsock notifies the component it can send something. -- Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html -- [EMAIL PROTECTED] http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Flow control
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 56kbps connection to send the data and you try to send for example 1mbps of data using the send routine, the internal buffer will keep growing and growing and growing, I don´t know if this is correct, 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. I have an Client / Server application for IP Camera Surveillance (www.digifort.com.br), and one feature of it works like this, the server receives images from the IP Cameras and retransmits those images to the clients connected to this server, but I have have an input from the camera at any rate (for example 30FPS that will give me an avg of 900KB/s) and the clients can be connected over the internet, but the client internet bandwidth will not be able to receive 900KB/s of data, nor the server internet connection will be able to transmit the images to the client at this rate, so, if I just receive the images and try to send it without any verification to the client, my server internal buffer will grow, and grow and grow because I can´t send this data that I´m receiveing, fast enought. So, to solve this I have made a server client class derived from TWSocketClient and implements the following procedure: function TSocketConexao.GetCanSendWithoutBuffering: Boolean; begin FBufHandler.Lock; try //If the internal buffer is empty, return TRUE, else, return FALSE Result := FBufferedByteCount = 0; finally FBufHandler.UnLock; end; end; And I have overriden the Send function to be like this: function TSocketConexao.Send(const Data: TWSocketData; Len: Integer): Integer; begin //Default return Result := 0; //Check if we have enouth space on send buffer if (MaxSendBuffer 0) and (SendBufferSize = FMaxSendBuffer) then exit; //Send the data using the Send routine from base class Result := inherited Send(Data, Len); end; As you can see, I have also implemented a property called MaxSendBuffer, with this I can specify how much data I can store into ICS internal buffer, if I store data on it (It may store more data than MaxSendBuffer permits into one call, but on the next call if I have data into internal buffer that is bigger than MaxSendBuffer, then, this routine simply doesn´t send the data and returns 0 (Data cannot be sent) So externally, when I call my new send routine it can returns me the len of buffered data or 0 if data cannot be put into internal buffer, so, if I try to send and it returns me 0, I have to wait to try to send data again. On my particular case, I can just discart data that cannot be sent to the clients, because my data is camera images, and what will happen is that the client will just receive images at a lower frame rate, because the server is discarting the images that it cannot send to the client, but in your case I think that you have to send all the data, so, you should implement some external checking, 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. Trying to understand how TIcsBufferHandler works, it appears to be multiple 1,460 byte blocks (TIcsBuffer), with new blocks being added if data can not be sent sufficiently fast. So I guess the answer to my question is there is no flow control and the buffers will just keep growing if data can not be sent fast enough, until the application runs out of memory. Angus -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] HttpSvr send picture stream
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) (Actually, my
source is written in Delphi, but should be easy to port to C++):
//Create the stream to send the data
StreamImg := TMemoryStream.Create;
try
//Read the data from my internal JPEG buffer
Cam.Comunicacao.HTTPImg.ReadImage(StreamImg);
//Fill the file data and send
AResponseInfo.ContentType :=
FHTTP.MIMETable.GetFileMIMEType('.jpg');
AResponseInfo.ContentLength := StreamImg.Size;
AResponseInfo.WriteHeader;
AContext.Connection.IOHandler.Write(StreamImg);
finally
StreamImg.Free;
end;
- Original Message -
From: xmedia [EMAIL PROTECTED]
To: 'ICS support mailing' twsocket@elists.org
Sent: Sunday, November 19, 2006 1:49 AM
Subject: [twsocket] HttpSvr send picture stream
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 server load. Because I can expediate the
process by open a few clients requesting pictures at half second
interval -
which can kill the http server over one night. I have been trying very
hard
to find out what's wrong here with no luck. The source file is similar to
theHttp Svr demo project - except I replaced the Time portion with JPEG
stream.
Here is what I put in OnGetDocument:
String URL = ((THttpConnection *)Client)-Path;
if(URL.SubString(1, 6)==/frame)
{
Flags = hgWillSendMySelf;
frame[0]-Position = 0; //frames[0] is where the jpeg file stream
stored. If saved to disk, you can get a jpeg file.
String Header = HTTP/1.1 200 OK\r\n
Content-Type: image/jpeg\r\n
Content-Length: + IntToStr(frame[0]-Size)+
\r\n\r\n;
TMemoryStream *Stream = new TMemoryStream;
Stream-Write(Header.data(), Header.Length());
Stream-CopyFrom(frame[0], 0);
Stream-Seek(0, 0);
Flags = hgWillSendMySelf;
((TMyHttpConnection *)Client)-DocStream = Stream;
((TMyHttpConnection *)Client)-SendStream();
}
Thanks - kyin
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://www.elists.org/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://www.elists.org/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
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 how TIcsBufferHandler works, it appears to be multiple 1,460 byte blocks (TIcsBuffer), with new blocks being added if data can not be sent sufficiently fast. 1460 is just the default. You have a property to change it. It has been selected because it correspond to the data size available in the largest Ethernet packet, thus optimizing packet fragmentation when using Ethernet. So I guess the answer to my question is there is no flow control and the buffers will just keep growing if data can not be sent fast enough, until the application runs out of memory. I still don't understand your problem. Are you willing to have a blocking Send method ? Could you re-explain your problem as seen from the highest level ? -- Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html -- [EMAIL PROTECTED] http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Flow control
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 connection to send the data and you try to send for example 1mbps of data using the send routine, the internal buffer will keep growing and growing and growing, I don´t know if this is correct, 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. It is correct. The idea of flow control with TWSocket is to send a data chunk (for example 4KB) and then from the OnDataSent event get the next data chunk. This way the buffer never grow beyond 4KB. This is what the FTP and HTTP component do. They could read files very fast but this would simply load most of the file into the buffer (RAM). So it read one chunk from the file and then from OnDataSent read the next chunk. On the network, the sending doesn't really send since when TWSocket has emptyed his buffer (OnDataSent is triggered at that time), winsock has his own buffer (8KB by default) filled. So while the application refill TWSocket buffer, winsock still send data to the network from his own buffer. -- Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html -- [EMAIL PROTECTED] http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Flow control
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 to send once the internal buffers reach a certain limit by checking BufferedByteCount (ignoring BuffSize which is clearly nothing to do with total buffer size). Angus -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Flow control
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, the server receives images from the IP Cameras and retransmits those images to the clients connected to this server 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 channels of UDP. I guess UDP is used to avoid flow control issues, packets are lost if not received. I have also implemented a property called MaxSendBuffer I think this needs to go into TWSocket. Angus -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Flow control
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 all channels and also streams eight channels of UDP. I guess UDP is used to avoid flow control issues, packets are lost if not received. I have also implemented a property called MaxSendBuffer I think this needs to go into TWSocket. Agreed. Also, for streaming real time data there are special protocols available: RTP (RFC 1889) and RTCP (RFC 1890). They are used for instance in VOIP/SIP. May be interesting? --- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Flow control
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 random streams of data around. But I've now created a new component to do much the same thing, which is why I'm trying to 'bullet proof' it, I'll be announcing it in a couple of days once I've integrated it into a few of my applications, replacing lots of horrible code. Angus -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Flow control
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 disk, ... The component offer anything needed to implement the required processing by the application. Have you notice BufferedByteCount property ? Just examine his value after Send() or PutDataInSendBuffer(). You'll know if you reached your limit. You may also use OnDataSent event which is triggered when BufferedByteCount becomes 0. Use OnSendData (do not confuse it with OnDataSent) which is triggered each time the component write something into winsock own buffer. IMO, you have all the required tools ! Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html -- [EMAIL PROTECTED] The author for the freeware multi-tier middleware MidWare The author of the freeware Internet Component Suite (ICS) http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Flow control
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 your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Flow control
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 allow an application to crash out of memory without any earlier errors. Failing Send if the buffered text reaches a limit, say 32K or something, seems sensible in the component, rather than expected every user to try and understand the buffering. Angus -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
