[twsocket] Please ignore spam message from me. Yahoo servers may have been hacked
I'm still investigating this, but it looks like Yahoo's mail servers may have been hacked and someone harvested parts of my Contact List for spamming. Here's an article from yesterday on the Yahoo server hack: http://www.infosecurity-magazine.com/view/29887/yahoo-hacked-in-the-ultimate-full-disclosure-full-exploitation/ Sincerely,Robert -- 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] TWSocket closing after every transactionwithexternal HTTP server
Hello Arno, Yes it is looking like I'll need to walk the user through using a packet sniffer. The external devices are all the exact same with some variations in the firmware. However, all the responses I've collected so far from different users show in their response headers support for HTTP 1.0 but with support for the keep-alive flag and the associated time-out and max-requests line too. The problem is only happening to one user so far but there may be others. I definitely mean HTTP Keep-Alive. I connect to the external server with a plain old TWSocket (not THttpClient) and craft the HTTP requests myself, but the external device is definitely acting as an HTTP server. Robert. --- On Thu, 4/5/12, Arno Garrels arno.garr...@gmx.de wrote: From: Arno Garrels arno.garr...@gmx.de Subject: Re: [twsocket] TWSocket closing after every transactionwithexternal HTTP server To: ICS support mailing twsocket@elists.org Date: Thursday, April 5, 2012, 9:42 AM robertoschler wrote: Hello Arno, Sending the Keep-Alive header line doesn't guarantee a HTTP server keeps the connection alive. True but in this case the external device is the same for all users. It's a mobile web cam, same model and same firmware. That's whey I'm wondering if it's an O/S issue. Just to clarify, some clients are disconnected immediately after the device/server response has been received and some are not (only after 30 seconds idle timeout)? The device is not the same, but another one, however the same model and firmware? What do you mean by the external device have the keep-alive flag set to TRUE? HTTP keep-alive or TCP keep-alive? In order to figure out who closes the connection it helps to log communication between the peers with a network sniffer such as the free WireShark. -- Arno -- 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] TWSocket closing after every transaction with external HTTP server
Hello, I have a Delphi 6 application that talks to an external device that acts as an HTTP server. I am using the ICS TWSocket components for this application. I open up a socket to talk to the device and handle the necessary header and body crafting to talk to the server. In other words, I am not using the ICS HTTP client component but using the lower level TWSocket component and handling the necessary HTTP handshaking myself. The headers I craft and send to the external device have the keep-alive flag set to TRUE. On my system, after I send anything to the external device, the connection will stay open continuously and will not close until approximately 30 seconds of inactivity occurs (30 seconds where I don't make any requests of the external device as an HTTP server). I don't know if the external device closes it or if Microsoft Windows does it. But the important point is that normally I can do multiple sends and the connection will stay open until I send nothing for about 30 seconds. This works fine and is what my code expects. However, on some of my users systems the socket is closing after every send. I do have code that checks for a closed socket and attempts a reconnect to the external device if necessary, but does not expect to have to do a reconnect with each transaction. My questions are: Is there a system setting for sockets that might be causing this anomalous behavior on some users systems? If so, are there Windows API function calls I can use to query the offending parameter and then set it to the expected close on 30 seconds of inactivity instead of with each transaction? If so, can I, or how do I do it in a manner that will not adversely affect any other programs running on the users system? Thanks, Robert -- 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] TWSocket closing after every transaction with external HTTP server
Hello Dod, I know the socket is closed because the TWSocket OnSessionClosed() event fires. There are no proxies because the external device is on the Intranet (same router and network) as the PC. It's a local peer connection. Robert. --- On Thu, 4/5/12, Dod do...@yahoo.com wrote: From: Dod do...@yahoo.com Subject: Re: [twsocket] TWSocket closing after every transaction with external HTTP server To: ICS support mailing twsocket@elists.org Date: Thursday, April 5, 2012, 5:36 AM Hello, How do you now socket has been closed ? have you done some tcpdump compare between wroking and non-working system ? May be some users are going out thru a proxy that remove the keep-alive ? regards. r Hello, r I have a Delphi 6 application that talks to an external device that acts as an HTTP server. I am using the ICS TWSocket components for this application. I open up a socket to talk to the device r and handle the necessary header and body crafting to talk to the server. In other words, I am not using the ICS HTTP client component but using the lower level TWSocket component and handling the r necessary HTTP handshaking myself. r The headers I craft and send to the external device have the keep-alive flag set to TRUE. On my system, after I send anything to the external device, the connection will stay open continuously and r will not close until approximately 30 seconds of inactivity occurs (30 seconds where I don't make any requests of the external device as an HTTP server). I don't know if the external device closes r it or if Microsoft Windows does it. But the important point is that normally I can do multiple sends and the connection will stay open until I send nothing for about 30 seconds. This works fine r and is what my code expects. r However, on some of my users systems the socket is closing after every send. I do have code that checks for a closed socket and attempts a reconnect to the external device if necessary, but does r not expect to have to do a reconnect with each transaction. r My questions are: r Is there a system setting for sockets that might be causing this anomalous behavior on some users systems? r If so, are there Windows API function calls I can use to query the offending parameter and then set it to the expected close on 30 seconds of inactivity instead of with each transaction? r If so, can I, or how do I do it in a manner that will not adversely affect any other programs running on the users system? r Thanks, r Robert r -- r To unsubscribe or change your settings for TWSocket mailing list r please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket r 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 -- 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] TWSocket closing after every transaction withexternal HTTP server
Hello Arno, Sending the Keep-Alive header line doesn't guarantee a HTTP server keeps the connection alive. True but in this case the external device is the same for all users. It's a mobile web cam, same model and same firmware. That's whey I'm wondering if it's an O/S issue. Robert. --- On Thu, 4/5/12, Arno Garrels arno.garr...@gmx.de wrote: From: Arno Garrels arno.garr...@gmx.de Subject: Re: [twsocket] TWSocket closing after every transaction withexternal HTTP server To: ICS support mailing twsocket@elists.org Date: Thursday, April 5, 2012, 8:18 AM robertoschler wrote: I know the socket is closed because the TWSocket OnSessionClosed() event fires. There are no proxies because the external device is on the Intranet (same router and network) as the PC. It's a local peer connection. Sending the Keep-Alive header line doesn't guarantee a HTTP server keeps the connection alive. Obviously there's some idle timeout configured at the server side. May be you can issue some dummy request in intervalls in order to work around this. However some HTTP servers prevent this as well by limiting the maximum number of requests per 'session'. -- Arno -- 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] Problems with TWSocket and Skype
Hello Arno, I'll try the wsoNoReceiveLoop option, thanks. make sure that you do not overflow the internal send buffer I do that already. Whenever I go to transmit audio (call Send), I check the buffered byte count waiting in the send queue and if it's non-zero I drop frames (ignore the audio to be sent and don't make a call to Send). The send-to-Skype socket does not die like the receive-from-Skype socket, it keeps sending but drops frames at a huge rate as described above. I have a statistics screen that shows me this in real time. Sincerely, Robert --- On Mon, 2/6/12, Arno Garrels arno.garr...@gmx.de wrote: From: Arno Garrels arno.garr...@gmx.de Subject: Re: [twsocket] Problems with TWSocket and Skype To: ICS support mailing twsocket@elists.org Date: Monday, February 6, 2012, 11:38 PM robertoschler wrote: My application acts as a middleman between an external WiFi webcam device relaying audio from its microphone to Skype's input audio port and relaying audio from Skype's output audio port to the webcam device's speaker. Include wsoNoReceiveLoop in TWSocket.ComponentOptions and make sure that you do not overflow the internal send buffer, it would grow and grow otherwise limited only by the amount of available memory. Handle event OnDataSent to Send next data chunks, property AllSent may be useful in this context as well. -- 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 -- 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] Problems with TWSocket and Skype
Hello Angus, It's TCP. As far as I know, no visual components are updated since the sockets have their own client threads. (Multithreaded = TRUE and a client thread is started after the TWSocket instance is created. The first thing the client thread does in its Execute() method is use the ThreadAttach() method to switch the TWSocket's instance's message loop to the client thread. Then it enters a custom message pump that calls GetMessage() and does the usual translate/dispatch calls). Please see my reply to Francois that contains the thread's Execute() method. Thanks, Robert --- On Mon, 2/6/12, Angus Robertson - Magenta Systems Ltd an...@magsys.co.uk wrote: From: Angus Robertson - Magenta Systems Ltd an...@magsys.co.uk Subject: Re: [twsocket] Problems with TWSocket and Skype To: twsocket@elists.org Date: Monday, February 6, 2012, 11:45 PM My application acts as a middleman between an external WiFi webcam device relaying audio from its microphone to Skype's input audio port and relaying audio from Skype's output audio port to the webcam device's speaker. I am using ICS on both sides now. TWSocket works just fine with the external WiFi webcam, however, I can't make it work with Skype. The audio going to Skype is frequently jamming up whereby the buffered byte count rises quickly for short durations, enough to make the audio stream going to Skype unusable (calling TWSocket.Send). The socket receiving audio from Skype receives about 11 to 20 data deliveries successfully and then just dies (OnDataAvailable stops firing). The connection stays open, but Skype stops sending audio permanently. Is this TCP or UDP? As François says, the most likely issue is another part of your application pre-empting ICS events, such as updating visual components. You can also try increasing the IP buffer sizes, which are SocketRcvBufSize and SocketSndBufSize to 64K, which will also speed up data transfers. I've tested transfers at over 250Mbit/sec. 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
[twsocket] Problems with TWSocket and Skype
Hello, A couple of years ago I tried using TWSocket with Skype to send audio back and forth between my Delphi 6 application and the Skype client. I never could get it to work until I switched to the Indy components. Since then I've used ICS in several applications they have always worked great. Now I have another application that interfaces with Skype and again I am having trouble trying to get TWSocket to work with Skype. My application acts as a middleman between an external WiFi webcam device relaying audio from its microphone to Skype's input audio port and relaying audio from Skype's output audio port to the webcam device's speaker. I am using ICS on both sides now. TWSocket works just fine with the external WiFi webcam, however, I can't make it work with Skype. The audio going to Skype is frequently jamming up whereby the buffered byte count rises quickly for short durations, enough to make the audio stream going to Skype unusable (calling TWSocket.Send). The socket receiving audio from Skype receives about 11 to 20 data deliveries successfully and then just dies (OnDataAvailable stops firing). The connection stays open, but Skype stops sending audio permanently. Both sockets for the pair of connections are spawned by a listening socket. The way you tell the Skype client to receive audio from your application is to open a socket on a port number of your choice and Listen. You then tell Skype the port number you are using and Skype connects to you on that port. The same goes for the socket you use send audio to Skype. In both cases you Listen and Skype connects to you on the given port. The difference of course being that you repeatedly handle OnDataAvailable() events on the socket that is receiving audio from Skype, and repeatedly call Send() on the socket that is sending audio to Skype. I'd rather keep things ICS all around but I'm close to switching to Indy on the Skype side. I recently found out that Skype uses Indy for its Windows clients. I'm also aware that Indy uses a thread that blocks to do its work as opposed to TWSocket which uses a message loop. Can anyone speculate as to what about Indy's sockets are more compatible with Skype than (at least for me) TWSocket sockets? What could I try to quickly fix this situation, perhaps by more closely emulating Indy's behavior? Thanks, Robert -- 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] Help needed with TWSocket descendant with background thread message loop
I have a TWSocket descendant called TWSocketClientDeluxe. It does its work on
a background thread. I have confirmed that this is the case by setting
breakpoints on various events and inspecting the Threads window to make sure it
is not on the main thread. It creates its own client thread and its
Multithreaded property is TRUE.
I recently changed my Send() method override to post buffers to the client
thread so that the actual Send() takes place on the worker thread and not on
the thread that calls TWSocketClientDeluxe.Send(). To facilitate this, the
custom message loop I created to replace the base class method has custom
windows messages for executing certain relevant requests and for processing the
Send() data requests posted by TWSocketClientDeluxe.Send(). The client thread
message loop then takes those buffers and calls a method I created called
BgSend(). That method simply calls the base class Send() method (inherited
Send()). I am having various problems so I am posting the code I wrote for the
client thread's custom message loop to see if any of you see any problems with
it. It's a little lengthy so my apologies in advance.
The reason I have taken such extreme measures like moving to a background
thread and decoupling the Send() operation is to avoid any thread blocking
issues as much as I can. My application is the middleman between two sockets
that cooperate in a multiple real-time audio streams. Therefore, I have to
grab the buffer from one socket and send it out the other as quickly as
possible. Hence the extreme measures. Note, the interface object retrieved
from the MsgRec was already _AddRef'd an extra time before it was posted to
make sure it did not destroy prematurely when recovered by the custom message
loop.
Here's the code, hopefully the formatting doesn't fall apart in your E-mail
reader. Please comment on anything that is wrong or might cause instabilities
or problems:
-- Custom Message Loop For Socket Client Thread
while GetMessage(MsgRec, 0, 0, 0) do
begin
TranslateMessage(MsgRec);
// Is it a request to execute a custom background thread request?
if MsgRec.message = WM_BG_CUSTOM_SOCKET_REQUEST then
begin
// ATI: 1-10-2012: Custom background thread request.
//
// If our owner socket is a TWSocketClientDeluxe instance and
// we have a custom background request event handler, then
// call it now.
if WSocket is TWSocketClientDeluxe then
begin
theSockCliDeluxe := TWSocketClientDeluxe(WSocket);
if Assigned(theSockCliDeluxe.OnBgCustomRequestProc) then
theSockCliDeluxe.OnBgCustomRequestProc(MsgRec);
end; // if WSocket is TWSocketClientDeluxe then
end
// Is it a request to reconnect with the same settings as the
// last connect (current settings)?
else if MsgRec.message = WM_BG_SOCKET_RECONNECT then
begin
// If we are not closed then this is an error.
if not (WSocket.State = wsClosed) then
raise Exception.Create('(TClientThread.Execute) A reconnect request
was received when our socket was not in the closed state. Socket name: ' +
WSocket.Name);
// --- RECONNECT ---
// Re-connect.
WSocket.Connect;
end // if (GAUNTLET) then
else if MsgRec.message = WM_BG_SOCKET_SEND_REQUEST then
begin
// -- SEND DATA REQUEST --
// Recover the send data request interface.
intf := nil;
P := Pointer(MsgRec.lParam);
if not Assigned(P) then
raise Exception.Create('(TClientThread.Execute) Long parameter was
not assigned, received pointer invalid while recovering the
IPostBufferToCollection interface.');
Move(P, intf, sizeof(intf));
if not Assigned(intf) then
raise Exception.Create('(TClientThread.Execute) Received an
unassigned interface object.');
if not Supports(intf, IClientSocketSendDataRequest,
intfCliSockSendDataReq) then
raise Exception.Create('(TClientThread.Execute) Interface object
received is not a IClientSocketSendDataRequest interface.');
if not Assigned(intfCliSockSendDataReq.data) then
raise Exception.Create('(TClientThread.Execute) The send data
request has an unassigned data pointer.');
if intfCliSockSendDataReq.dataLen = 0 then
raise Exception.Create('(TClientThread.Execute) The send data
request''s buffer length is less than or equal to 0.');
// Send the data now but use the background send method that
// calls the inherited Send() method directly or we
// will create a recursive self-posting situation.
with WSocket as TWSocketClientDeluxe do
BgSend(intfCliSockSendDataReq.data, intfCliSockSendDataReq.dataLen);
// Release the interface variables we used.
[twsocket] TWSocket and Skype, anyone done that?
If anybody has used TWSocket to communicate with Skype when sending/receiving Skype audio via a port, please share any tips or problems that you had when doing so. Thanks, Robert -- 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] Does a call to TWSocket.Send have to be on the same thread as the socket?
I have a TWSocket component with a background thread. I do use the Thread.Attach method as I saw in the sample code to switch it to the background thread I create, and I also set the socket's Multithreaded property to true. I also double-checked with the Delphi thread window to confirm it's doing work on a background thread. If I make a Send call to that socket, does it have to occur on the same thread as the worker thread? Or can I call it's Send method from another thread? I looked at the WSocket.pas code and I didn't see anything that looked like it wasn't thread-safe, but I'm having some strange problems like missing OnDataAvailable() events so I wanted to check. Thanks, Robert -- 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] StatusCode of 0, ReasonPhrase = 'OK
I read about others having this same problem during a web search. I'm getting this problem too. I'm using THttpCli1 in a tight loop on an external thread to send commands to a robot accepting commands as an HTTP server. I set THttpCli's Multithreaded property to TRUE. But I'm getting tons of errors from the Post operation due to the StatusCode coming back as 0 with the the ReasonPhrase = 'OK'. Other times the call works properly returning a 200 StatusCode. The returned document is empty when the StatusCode is 0, otherwise it returns the correct response document. http://www.mail-archive.com/twsocket@elists.org/msg12385.html Did anyone ever get any more information on what causes this and how to solve this? The call sent, as far as URL, Post data, etc. is identical each pass and the call happens about every 100 milliseconds. I recognize that it may be the robot/server actually returning that error code, however this doesn't happen when I run the code on the main VCL thread with Multithreaded set to FALSE. Thanks, Robert -- 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] TWSocket stops receiving where TClientSocket just keeps going
Hello Wilfried, Thank you for your reply. It appears to be something with my application but I don't know what. I grabbed your SocketSpy program and set it up to act as a proxy between the streaming image server and my program. Your log kept accumulating incoming data from the server while my app, which was connected to SocketSpy as an incoming client, stopped firing DataAvailable() events after a certain number of received frames, just as I described before. Now some details. My app is also a proxy server like SocketSpy. I looked at the SocketSpy code and here is the only crucial difference I could find between your code and mine. When your server socket accepts a connection you create a client socket that creates it's own REMOTE client socket when a new connection is accepted. This REMOTE client socket immediately connects to the other end other end of the proxy link. From the client socket's Data Available handler you immediately send the data to the REMOTE socket and vice-a-versa. In my program when I accept a new connection with TWSocketServer I just create a client socket. This results in a message being posted to the host form telling it a new client has been connected and the current connection count. If the client count is now greater than 0 for the first time, a single plain vanilla TWSocket control then connects to the streaming image server completing the other end of my proxy link. (Details on why I use this architecture are below). To facilitate data transfer I use windows messages posted to the host form. When *any* of the Clients to TWSocketServer fire the Data Available event, I post a message to the host form notifying it of the new data. The host form then calls SendStr() on the single plain vanilla TWSocket control connected to the image streaming server. Conversely, when the plain vanilla TWSocket control fires its Data Available event, a message is posted to the host form who then sends the data to ALL clients connected to the TWSocketServer instance. I do this so I can have a one-to-many proxy link, where multiple clients can receive the image stream from the image server. Also, I use the windows messaging technique for safety purposes so that I am not trying to send large amounts of data to the other end of the proxy link from within the Data Available handler itself. By using windows messages to trigger the sends I am moving the send outside the scope of the Data Available handler. Note, I have code in *every* event handler for all sockets, including for the Error and BgException events, and I am not getting any error reports. I also check all ErrorCode's on those events that provided that parameter, and report any non zero code ErrorCode occurrences. There have been no such occurrences. Do you have any ideas for tests or tips on trying to diagnose why the Data Available event on the plain vanilla TWSocket component connected to the image streaming server would go dead after receiving successfully for a short time? Thanks for your help, Robert --- On Fri, 6/5/09, Wilfried Mestdagh wilfr...@mestdagh.biz wrote: From: Wilfried Mestdagh wilfr...@mestdagh.biz Subject: Re: [twsocket] TWSocket stops receiving where TClientSocket just keeps going To: ICS support mailing twsocket@elists.org Date: Friday, June 5, 2009, 3:30 AM Hello Robert, To be absolutely sure if it is the sending or receiving application I suggest you put SocketSpy between it. You find it on user made page. Then we are sure in wich application is a bug and we can search deeper. --- Rgds, Wilfried [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html http://www.mestdagh.biz Thursday, June 4, 2009, 17:58, robertoschler wrote: I have an application that opens an outgoing connection to an MJPEG streaming server (server push using MIME multi-part boundary method). With my TWSocket code, I connect fine and then I get an arbitrary number of frames until the connection appears to stop receiving data, permanently. The data available event never fires again until I close the connection and reconnect. This happens pretty quick. Sometimes it's a small number of frames (e.g. - 1 to 7). Other times I get a nice chunk of about 30 to 50 frames, but always the data reception just dries up. To make sure the server was not stopping transmission, I coded up a simple example using the included Delphi 6 TClientSocket component. I set it to non-blocking mode which is how I use TWSocket too. It did not exhibit the problem. It kept receiving frames until I shut down the connection. How can I diagnose and or fix the problem with my TWSocket code? I would prefer to use that instead. Note: I am using Delphi 6 Pro and ICS version 5. Thanks, Robert -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman
Re: [twsocket] TWSocket stops receiving where TClientSocket just keeps going
Hello again Wilfried, A little extra data. My Data Available event handler grabs the number of waiting bytes in the queue from the RcvdCount property (I use it to size the receive buffer). If the byte count is 0, I just ignore the Data Available event. That is, I do nothing. I just added code to the Data Available event handler to add a line to my session log whenever I get a Data Available event where the RcvdCount is 0. I'm getting a ton of Data Available events where the RcvdCount is 0 on the plain vanilla TWSocket instance connected to the image streaming server. Any ideas what could cause that to happen? Thanks, Robert --- On Fri, 6/5/09, robertoschler robertosch...@yahoo.com wrote: From: robertoschler robertosch...@yahoo.com Subject: Re: [twsocket] TWSocket stops receiving where TClientSocket just keeps going To: ICS support mailing twsocket@elists.org Date: Friday, June 5, 2009, 7:43 PM Hello Wilfried, Thank you for your reply. It appears to be something with my application but I don't know what. I grabbed your SocketSpy program and set it up to act as a proxy between the streaming image server and my program. Your log kept accumulating incoming data from the server while my app, which was connected to SocketSpy as an incoming client, stopped firing DataAvailable() events after a certain number of received frames, just as I described before. Now some details. My app is also a proxy server like SocketSpy. I looked at the SocketSpy code and here is the only crucial difference I could find between your code and mine. When your server socket accepts a connection you create a client socket that creates it's own REMOTE client socket when a new connection is accepted. This REMOTE client socket immediately connects to the other end other end of the proxy link. From the client socket's Data Available handler you immediately send the data to the REMOTE socket and vice-a-versa. In my program when I accept a new connection with TWSocketServer I just create a client socket. This results in a message being posted to the host form telling it a new client has been connected and the current connection count. If the client count is now greater than 0 for the first time, a single plain vanilla TWSocket control then connects to the streaming image server completing the other end of my proxy link. (Details on why I use this architecture are below). To facilitate data transfer I use windows messages posted to the host form. When *any* of the Clients to TWSocketServer fire the Data Available event, I post a message to the host form notifying it of the new data. The host form then calls SendStr() on the single plain vanilla TWSocket control connected to the image streaming server. Conversely, when the plain vanilla TWSocket control fires its Data Available event, a message is posted to the host form who then sends the data to ALL clients connected to the TWSocketServer instance. I do this so I can have a one-to-many proxy link, where multiple clients can receive the image stream from the image server. Also, I use the windows messaging technique for safety purposes so that I am not trying to send large amounts of data to the other end of the proxy link from within the Data Available handler itself. By using windows messages to trigger the sends I am moving the send outside the scope of the Data Available handler. Note, I have code in *every* event handler for all sockets, including for the Error and BgException events, and I am not getting any error reports. I also check all ErrorCode's on those events that provided that parameter, and report any non zero code ErrorCode occurrences. There have been no such occurrences. Do you have any ideas for tests or tips on trying to diagnose why the Data Available event on the plain vanilla TWSocket component connected to the image streaming server would go dead after receiving successfully for a short time? Thanks for your help, Robert --- On Fri, 6/5/09, Wilfried Mestdagh wilfr...@mestdagh.biz wrote: From: Wilfried Mestdagh wilfr...@mestdagh.biz Subject: Re: [twsocket] TWSocket stops receiving where TClientSocket just keeps going To: ICS support mailing twsocket@elists.org Date: Friday, June 5, 2009, 3:30 AM Hello Robert, To be absolutely sure if it is the sending or receiving application I suggest you put SocketSpy between it. You find it on user made page. Then we are sure in wich application is a bug and we can search deeper. --- Rgds, Wilfried [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html http://www.mestdagh.biz Thursday, June 4, 2009, 17:58, robertoschler wrote: I have an application that opens an outgoing connection to an MJPEG streaming server (server push using MIME multi-part boundary method). With my TWSocket code, I connect fine and then I get an arbitrary
Re: [twsocket] TWSocket stops receiving where TClientSocket just keeps going
Hello Wilfried, Well now I know the problem. The Overbyte web site says RcvdCount is unreliable. Their example shows the use of a 8192 size buffer in Data Available to receive whatever data may be there and to check the return of the Receive() call to know how much data was delivered. I assume this means that the maximum amount of data received during any Data Available event is 8192. It's amazing how so small a thing can cost you so much time. I'm going to recode and retest now. Thanks, Robert --- On Fri, 6/5/09, robertoschler robertosch...@yahoo.com wrote: From: robertoschler robertosch...@yahoo.com Subject: Re: [twsocket] TWSocket stops receiving where TClientSocket just keeps going To: ICS support mailing twsocket@elists.org Date: Friday, June 5, 2009, 8:10 PM Hello again Wilfried, A little extra data. My Data Available event handler grabs the number of waiting bytes in the queue from the RcvdCount property (I use it to size the receive buffer). If the byte count is 0, I just ignore the Data Available event. That is, I do nothing. I just added code to the Data Available event handler to add a line to my session log whenever I get a Data Available event where the RcvdCount is 0. I'm getting a ton of Data Available events where the RcvdCount is 0 on the plain vanilla TWSocket instance connected to the image streaming server. Any ideas what could cause that to happen? Thanks, Robert --- On Fri, 6/5/09, robertoschler robertosch...@yahoo.com wrote: From: robertoschler robertosch...@yahoo.com Subject: Re: [twsocket] TWSocket stops receiving where TClientSocket just keeps going To: ICS support mailing twsocket@elists.org Date: Friday, June 5, 2009, 7:43 PM Hello Wilfried, Thank you for your reply. It appears to be something with my application but I don't know what. I grabbed your SocketSpy program and set it up to act as a proxy between the streaming image server and my program. Your log kept accumulating incoming data from the server while my app, which was connected to SocketSpy as an incoming client, stopped firing DataAvailable() events after a certain number of received frames, just as I described before. Now some details. My app is also a proxy server like SocketSpy. I looked at the SocketSpy code and here is the only crucial difference I could find between your code and mine. When your server socket accepts a connection you create a client socket that creates it's own REMOTE client socket when a new connection is accepted. This REMOTE client socket immediately connects to the other end other end of the proxy link. From the client socket's Data Available handler you immediately send the data to the REMOTE socket and vice-a-versa. In my program when I accept a new connection with TWSocketServer I just create a client socket. This results in a message being posted to the host form telling it a new client has been connected and the current connection count. If the client count is now greater than 0 for the first time, a single plain vanilla TWSocket control then connects to the streaming image server completing the other end of my proxy link. (Details on why I use this architecture are below). To facilitate data transfer I use windows messages posted to the host form. When *any* of the Clients to TWSocketServer fire the Data Available event, I post a message to the host form notifying it of the new data. The host form then calls SendStr() on the single plain vanilla TWSocket control connected to the image streaming server. Conversely, when the plain vanilla TWSocket control fires its Data Available event, a message is posted to the host form who then sends the data to ALL clients connected to the TWSocketServer instance. I do this so I can have a one-to-many proxy link, where multiple clients can receive the image stream from the image server. Also, I use the windows messaging technique for safety purposes so that I am not trying to send large amounts of data to the other end of the proxy link from within the Data Available handler itself. By using windows messages to trigger the sends I am moving the send outside the scope of the Data Available handler. Note, I have code in *every* event handler for all sockets, including for the Error and BgException events, and I am not getting any error reports. I also check all ErrorCode's on those events that provided that parameter, and report any non zero code ErrorCode occurrences. There have been no such occurrences. Do you have any ideas for tests or tips on trying to diagnose why the Data Available event on the plain vanilla TWSocket component connected to the image streaming server would go dead after receiving successfully for a short time? Thanks for your help, Robert --- On Fri, 6/5/09
Re: [twsocket] TWSocket stops receiving where TClientSocket just keeps going
Hello Wilfried, Just for the record everything works fine. Hopefully someone else can benefit from my little journey here. I no longer check RcvdCount and simply check the byte count returned by ReceiveStr. It works great. This is a relief because ICS is my preferred choice for socket work. Thanks for listening, Robert --- On Fri, 6/5/09, robertoschler robertosch...@yahoo.com wrote: From: robertoschler robertosch...@yahoo.com Subject: Re: [twsocket] TWSocket stops receiving where TClientSocket just keeps going To: ICS support mailing twsocket@elists.org Date: Friday, June 5, 2009, 8:40 PM Hello Wilfried, Well now I know the problem. The Overbyte web site says RcvdCount is unreliable. Their example shows the use of a 8192 size buffer in Data Available to receive whatever data may be there and to check the return of the Receive() call to know how much data was delivered. I assume this means that the maximum amount of data received during any Data Available event is 8192. It's amazing how so small a thing can cost you so much time. I'm going to recode and retest now. Thanks, Robert --- On Fri, 6/5/09, robertoschler robertosch...@yahoo.com wrote: From: robertoschler robertosch...@yahoo.com Subject: Re: [twsocket] TWSocket stops receiving where TClientSocket just keeps going To: ICS support mailing twsocket@elists.org Date: Friday, June 5, 2009, 8:10 PM Hello again Wilfried, A little extra data. My Data Available event handler grabs the number of waiting bytes in the queue from the RcvdCount property (I use it to size the receive buffer). If the byte count is 0, I just ignore the Data Available event. That is, I do nothing. I just added code to the Data Available event handler to add a line to my session log whenever I get a Data Available event where the RcvdCount is 0. I'm getting a ton of Data Available events where the RcvdCount is 0 on the plain vanilla TWSocket instance connected to the image streaming server. Any ideas what could cause that to happen? Thanks, Robert --- On Fri, 6/5/09, robertoschler robertosch...@yahoo.com wrote: From: robertoschler robertosch...@yahoo.com Subject: Re: [twsocket] TWSocket stops receiving where TClientSocket just keeps going To: ICS support mailing twsocket@elists.org Date: Friday, June 5, 2009, 7:43 PM Hello Wilfried, Thank you for your reply. It appears to be something with my application but I don't know what. I grabbed your SocketSpy program and set it up to act as a proxy between the streaming image server and my program. Your log kept accumulating incoming data from the server while my app, which was connected to SocketSpy as an incoming client, stopped firing DataAvailable() events after a certain number of received frames, just as I described before. Now some details. My app is also a proxy server like SocketSpy. I looked at the SocketSpy code and here is the only crucial difference I could find between your code and mine. When your server socket accepts a connection you create a client socket that creates it's own REMOTE client socket when a new connection is accepted. This REMOTE client socket immediately connects to the other end other end of the proxy link. From the client socket's Data Available handler you immediately send the data to the REMOTE socket and vice-a-versa. In my program when I accept a new connection with TWSocketServer I just create a client socket. This results in a message being posted to the host form telling it a new client has been connected and the current connection count. If the client count is now greater than 0 for the first time, a single plain vanilla TWSocket control then connects to the streaming image server completing the other end of my proxy link. (Details on why I use this architecture are below). To facilitate data transfer I use windows messages posted to the host form. When *any* of the Clients to TWSocketServer fire the Data Available event, I post a message to the host form notifying it of the new data. The host form then calls SendStr() on the single plain vanilla TWSocket control connected to the image streaming server. Conversely, when the plain vanilla TWSocket control fires its Data Available event, a message is posted to the host form who then sends the data to ALL clients connected to the TWSocketServer instance. I do this so I can have a one-to-many proxy link, where multiple clients can receive the image stream from the image server. Also, I use the windows messaging technique for safety purposes so that I am not trying to send large amounts of data to the other end of the proxy link from within the Data Available handler
Re: [twsocket] New component THttpAppSrv to build powerful web application server
Hello Francois, Excellent. Will THttpAppSrv work with Delphi 6 Pro? I'm still using that version for all my Delphi work and I use ICS with it a lot. Thanks, Robert --- On Fri, 5/22/09, Francois PIETTE francois.pie...@skynet.be wrote: From: Francois PIETTE francois.pie...@skynet.be Subject: [twsocket] New component THttpAppSrv to build powerful web application server To: twsocket@elists.org Date: Friday, May 22, 2009, 8:28 AM Hi ! I created a new component to build powerful web application servers. I have somehow documented the component in the wiki http://wiki.overbyte.be/wiki/index.php/THttpAppSrv and I have created a tutorial you can find here: http://wiki.overbyte.be/wiki/index.php/TutWebAppServer There is also a nice sample program OverbyteIcsWebAppServer in the internet folder. You will find the new component in ICS-V7 distribution (See How to get ICS at http://wiki.overbyte.be/wiki/index.php/FAQ) -- francois.pie...@overbyte.be The author of 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://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] Bad link to TWSocket mailing list sign up page (ICS)
PREFACE: The link on the certain pages on the Overbyte.be and nearly every archived TWSocket mailing list message that is supposed to take you to the mailing list sign up form is wrong: Look at the FAQ page: http://users.telenet.be/sonal.nv/ics/faq/Frame_index.html Which has this link which leads to a 404: http://www.elists.org/mailman/listinfo/twsocket This is the correct link to the mailing list sign up page: http://lists.elists.org/mailman/listinfo/twsocket Perhaps you can get elists.org to set up a redirect? There's thousands of archived messages with the bad link which turn up when a user searches the Web. Thanks, Robert -- 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] HTTP Post hanging during Basic authorization phase (2nd phase)
I am using Delphi Professional 6.0 pack 2 with ICS. I'm not sure what version of ICS I am using since I don't see the version number in the README. However, I checked HttPProt.pas and the final comment reads: Oct 15, 2004 V1.71 lotauro.mauri...@dnet.it enhanced basic and NTLM authentifications methods. Event OnNTLMAuthStep has been removed. I am trying to access a server that requires Basic Authentication. I can access the server without problem using FireFox. When I try it with THttpCli it hangs on the second attempt after it sends the request with the proper Authentication header line. I matched the Header data up as best as I could between what FireFox is sending and with what THttpCli sends during a Post attempt. I captured the Header and Data send and receive events and the Headers appear to be identical where it counts (Authorization, Content-Type, Accept, etc.). Note, I configured the Headers using the THttpCli properties, not by modifying the data in the OnCommand event (UserName, Password, Accept, ContentTypePost, etc.). I logged the transaction and I can see that THttpCli handles the initial 401 error, closes and reopens the connection, and makes the second attempt with the correct Authorization line in the Header data. I matched the encoded UserName/Password to the FireFox session and they are identical. However, after the request is sent with the Authorization data, THttpCli just hangs waiting for something until I Abort the connection. Does anyone know what is going wrong here or what I can try to debug it? I have included the log I captured during the THttpCli Post session. I have removed the encoded UserName/Password and added comments where I thought it might help. Thanks, Robert --- RESPONSE LOG Retrieving URL. HttpCli1: Socket state change: Invalid state HttpCli1: Socket state change: Invalid state HttpCli1: Socket state change: Invalid state HttpCli1: Socket state change: Invalid state HttpCli1: Session connected. HttpCli1: Socket state change: Invalid state HttpCli1: Request Header begins. HttpCli1: Before Header send.! HttpCli1: Command: POST /rev.cgi HTTP/1.0 HttpCli1: Command: Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 HttpCli1: Command: Content-Type: application/xml; charset=UTF-8 HttpCli1: Command: User-Agent: Mozilla/4.0 (compatible; ICS) HttpCli1: Command: Host: 127.0.0.1 HttpCli1: Command: Pragma: no-cache HttpCli1: Command: Content-Length: 26 HttpCli1: Request header ends. HttpCli1: Command: HttpCli1: Send begins. HttpCli1: Send data event, length: 26 HttpCli1: Send ends. // I DO NOT GET PAST THIS POINT DURING THE AUTHORIZATION ATTEMPT. HttpCli1: Header begins. HttpCli1: Header Data. HttpCli1: Header Data. HttpCli1: Header Data. HttpCli1: Header Data. HttpCli1: Header Data. HttpCli1: Header Data. HttpCli1: Header ends. HttpCli1: Socket state change: Invalid state HttpCli1: Header ends. HttpCli1: Document begins. HttpCli1: Doc data event, length: 173 HttpCli1: Document ended. HttpCli1: Session closed. // AUTHORIZATION ATTEMPT HttpCli1: Socket state change: Invalid state HttpCli1: Socket state change: Invalid state HttpCli1: Socket state change: Invalid state HttpCli1: Socket state change: Invalid state HttpCli1: Session connected. HttpCli1: Socket state change: Invalid state HttpCli1: Request Header begins. HttpCli1: Before Header send.! HttpCli1: Command: POST /rev.cgi HTTP/1.0 HttpCli1: Command: Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 HttpCli1: Command: Content-Type: application/xml; charset=UTF-8 HttpCli1: Command: User-Agent: Mozilla/4.0 (compatible; ICS) HttpCli1: Command: Host: 127.0.0.1 HttpCli1: Command: Pragma: no-cache HttpCli1: Command: Content-Length: 26 HttpCli1: Command: Authorization: Basic (encoded login details removed by me for privacy reasons but it matches the FireFox session) HttpCli1: Request header ends. HttpCli1: Command: HttpCli1: Send begins. HttpCli1: Send ends. // THttpCli HANGS HERE. // END RESPONSE LOG --- -- 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] HTTP Post hanging during Basic authorization phase (2nd phase)
Thanks Maurizio. That did the trick, it works now. Fortunately the new ICS (Version 5) hasn't affected anything in the current project, but I do have older projects that I made modifications to the ICS code which I will have to recode. That's why I hesitated at first to upgrade. Robert. --- On Fri, 1/23/09, Maurizio Lotauro lotauro.mauri...@dnet.it wrote: From: Maurizio Lotauro lotauro.mauri...@dnet.it Subject: Re: [twsocket] HTTP Post hanging during Basic authorization phase (2nd phase) To: ICS support mailing twsocket@elists.org Date: Friday, January 23, 2009, 7:12 PM Scrive robertoschler robertosch...@yahoo.com: I am using Delphi Professional 6.0 pack 2 with ICS. I'm not sure what version of ICS I am using since I don't see the version number in the README. However, I checked HttPProt.pas and the final comment reads: Oct 15, 2004 V1.71 lotauro.mauri...@dnet.it enhanced basic and NTLM authentifications methods. Event OnNTLMAuthStep has been removed. This version has some problem with authentication that was corrected in later versions. I suggest to upgrade to a more recent one. Bye, Maurizio. This mail has been sent using Alpikom webmail system http://www.alpikom.it -- 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
