Re: [twsocket] Delay in Socket Communication
I am using ICS ver5 for communication as server and client (TWSocket), But there is delay in data send by the server to the client . I am sending the data frequently about 1000 bytes at a time . but I am not getting at client site at that time but there is delay of 2 - 5 seconds on network . when I sent 50 to 200 bytes at a time I am getting it at right time with delay of 10 -100 miliseconds At present I have only one client connected to the server . And I set wSocket-BufSize = 3; Are you using TCP or UDP ? If you use TCP, do not change BufSize. How can I solve this problem . I have network bandwidth of 2MB/s. MB/s = MegaBytes per second. Or is this MegaBITS per second (Mbps) ? What is the physical support ? Is it Ethernet ? If it is not Ethernet, and you use TCP, it may help to REDUCE BufSize to the actual MTU (Maximum Transfer Unit) of the physical network, this will help winsock sending packet of that size which is always better. If you use UDP and you are sending large datagrams, those datagrams are split into smaller packets by the IP stack (not ICS) at the sender side and then reassembled into the original datagram size at the receiver side. It is usually not a good idea to send an UDP datagram larger than the MTU size so that datagrams are not split into many packets. Chances to have a bad datagram is much higher when it is split into packets. UDP is by definition an unreliable protocol. You have to add reliability at the application level. Read this http://wiki.overbyte.be/wiki/index.php/FAQ.Difference. What is the ping time ? What is the error rate on the network ? Use command line netstat -e to find out. TCP has automtatic retries so that it transparently offer a reliable transport, but with a high error rate, this may becomes slow because of retries. Also if you have a netwrok with different speeds, for example the network card in your PC is Gigabit Ethernet or FastEthernet and there is somewhere a slow serial link, then depending on the actual hardware, network may become very slow because of packet drop because of different speed and lack of buffer. TCP has a window size to accomodate this behaviour, but if window size is larger than buffering in the slowest part of the network, then performance are going to be very low because packets are dropped and need to be retransmitted. Please explain your physical network so that I better understand your environment. -- 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
Re: [twsocket] Delay in Socket Communication
Hi, I am using TCP My Network Bandwidth is 2 MegaBITS per second (Mbps) it is Ethernet On Thu, Feb 10, 2011 at 1:39 PM, Francois PIETTE francois.pie...@skynet.bewrote: I am using ICS ver5 for communication as server and client (TWSocket), But there is delay in data send by the server to the client . I am sending the data frequently about 1000 bytes at a time . but I am not getting at client site at that time but there is delay of 2 - 5 seconds on network . when I sent 50 to 200 bytes at a time I am getting it at right time with delay of 10 -100 miliseconds At present I have only one client connected to the server . And I set wSocket-BufSize = 3; Are you using TCP or UDP ? If you use TCP, do not change BufSize. How can I solve this problem . I have network bandwidth of 2MB/s. MB/s = MegaBytes per second. Or is this MegaBITS per second (Mbps) ? What is the physical support ? Is it Ethernet ? If it is not Ethernet, and you use TCP, it may help to REDUCE BufSize to the actual MTU (Maximum Transfer Unit) of the physical network, this will help winsock sending packet of that size which is always better. If you use UDP and you are sending large datagrams, those datagrams are split into smaller packets by the IP stack (not ICS) at the sender side and then reassembled into the original datagram size at the receiver side. It is usually not a good idea to send an UDP datagram larger than the MTU size so that datagrams are not split into many packets. Chances to have a bad datagram is much higher when it is split into packets. UDP is by definition an unreliable protocol. You have to add reliability at the application level. Read this http://wiki.overbyte.be/wiki/index.php/FAQ.Difference. What is the ping time ? What is the error rate on the network ? Use command line netstat -e to find out. TCP has automtatic retries so that it transparently offer a reliable transport, but with a high error rate, this may becomes slow because of retries. Also if you have a netwrok with different speeds, for example the network card in your PC is Gigabit Ethernet or FastEthernet and there is somewhere a slow serial link, then depending on the actual hardware, network may become very slow because of packet drop because of different speed and lack of buffer. TCP has a window size to accomodate this behaviour, but if window size is larger than buffering in the slowest part of the network, then performance are going to be very low because packets are dropped and need to be retransmitted. Please explain your physical network so that I better understand your environment. -- 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
Re: [twsocket] Delay in Socket Communication
I am using Antivirus on the server .can this effect and delay . You will find out once you add ping to provide some evidential diagnostics of the problem. Anti-virus software should only be looking at changed files, not TCP streams. But that term is now used to cover a lot more, such as firewalls, email monitoring, etc, which can cause unexpected internet issues. But since you only have a problem with a single remote client site, it's highly unlikely to be a server or software issue. 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
Re: [twsocket] Delay in Socket Communication
I am using TCP My Network Bandwidth is 2 MegaBITS per second (Mbps) it is Ethernet Well, it is not Ethernet. Maybe your computer is connected via Ethernet, but at 2 Mbps, it is surely not ethernet. Ethernet exists in 3 flavors: Ethernet (10 Mbps), fastEthernet (100 Mbps) and Gigabit Ethernet (1000 Mbps). OK, maybe it is ethernet but then you have an active element which reduce the bandwidth. As I asked, and if you want better help, please explain EXACTLY what the network is from end to end. -- 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
[twsocket] Proxy traversal error handling
Hi, Some proxies just close or reset the connection if, for instance, the remote server is not listening or if Socks authentication fails for some _technical reason. It's my understanding that in such cases SessionConnected should be triggered with an error 0 before SessionClose, is that correct? Currently both Socks and HTTP-Tunnel code in TWSocket don't do that but only trigger SessionClose, even without an error in case of close (fin). -- 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
Re: [twsocket] Proxy traversal error handling
Some proxies just close or reset the connection if, for instance, the remote server is not listening or if Socks authentication fails for some _technical reason. It's my understanding that in such cases SessionConnected should be triggered with an error 0 before SessionClose, is that correct? Currently both Socks and HTTP-Tunnel code in TWSocket don't do that but only trigger SessionClose, even without an error in case of close (fin). Yes, normally in case of a connection cannot be established, OnSessionConnected should be called with a non nul error argument and then OnSessionClosed with same argument. -- 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
[twsocket] disconnect problem with tcp socket
Hello, am building a chat system and when a user is disconnected from there host there id is stuck within the socket so am wondering is there anyway of removing dead IDs once connection is lost to server? thanks -- 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] disconnect problem with tcp socket
am building a chat system and when a user is disconnected from there host there id is stuck within the socket so am wondering is there anyway of removing dead IDs once connection is lost to server? In my opinion, the best way to handle this is to implement at the application layer a kind of ping. Your chat system surely use a kind of messaging between client and server. Just implement one more command from server to client: every minute your server send a noop command to the client which simply answers OK. If the client do'nt answer, then assume his connection is lost and cleanup your system. -- 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
Re: [twsocket] Proxy traversal error handling
Francois PIETTE wrote: Some proxies just close or reset the connection if, for instance, the remote server is not listening or if Socks authentication fails for some _technical reason. It's my understanding that in such cases SessionConnected should be triggered with an error 0 before SessionClose, is that correct? Currently both Socks and HTTP-Tunnel code in TWSocket don't do that but only trigger SessionClose, even without an error in case of close (fin). Yes, normally in case of a connection cannot be established, OK. OnSessionConnected should be called with a non nul error argument and then OnSessionClosed with same argument. Currently I do not think so. With a proxy we have a special case, in case the connection to the proxy is established successfully we delay OnSessionConnected until we either passed thru or got some error response from the proxy. Now if the proxy silently resets or closes the connection without prior returning any error response while the tunnel is not established yet the component should pass a proxy-specific error code to OnSessionConnected and the true winsock error code to SessionClosed IMO. Why must the error code in SessionClosed be faked as well? Note that the true error code on SessionClosed in case above can WSAECONNRESET or zero respectively. -- 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
Re: [twsocket] Proxy traversal error handling
I think the proxy implementation should be as transparent as possible. Of course with a proxy in the middle, we have two levels of errors and we have only one to return to the application. Without having thinked about it too much, I would say that OnSessionConnected and OnSessionClosed should use the actual error code, no matter where it was generated (proxy or distant system). And since we need a second layer of error, probably a proxy specific error should be reported, if any, in a new property. What do you think ? -- 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 - Original Message - From: Arno Garrels arno.garr...@gmx.de To: ICS support mailing twsocket@elists.org Sent: Thursday, February 10, 2011 3:32 PM Subject: Re: [twsocket] Proxy traversal error handling Francois PIETTE wrote: Some proxies just close or reset the connection if, for instance, the remote server is not listening or if Socks authentication fails for some _technical reason. It's my understanding that in such cases SessionConnected should be triggered with an error 0 before SessionClose, is that correct? Currently both Socks and HTTP-Tunnel code in TWSocket don't do that but only trigger SessionClose, even without an error in case of close (fin). Yes, normally in case of a connection cannot be established, OK. OnSessionConnected should be called with a non nul error argument and then OnSessionClosed with same argument. Currently I do not think so. With a proxy we have a special case, in case the connection to the proxy is established successfully we delay OnSessionConnected until we either passed thru or got some error response from the proxy. Now if the proxy silently resets or closes the connection without prior returning any error response while the tunnel is not established yet the component should pass a proxy-specific error code to OnSessionConnected and the true winsock error code to SessionClosed IMO. Why must the error code in SessionClosed be faked as well? Note that the true error code on SessionClosed in case above can WSAECONNRESET or zero respectively. -- 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] Proxy traversal error handling
Here is an idea: Since winsock errors are 10xxx, why don't we add 1 to the error code if it is coming from proxy? For example when proxy returns 10053, we return 20053. Regards, SubZero On Thu, Feb 10, 2011 at 7:01 PM, Francois PIETTE francois.pie...@skynet.bewrote: I think the proxy implementation should be as transparent as possible. Of course with a proxy in the middle, we have two levels of errors and we have only one to return to the application. Without having thinked about it too much, I would say that OnSessionConnected and OnSessionClosed should use the actual error code, no matter where it was generated (proxy or distant system). And since we need a second layer of error, probably a proxy specific error should be reported, if any, in a new property. What do you think ? -- 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 - Original Message - From: Arno Garrels arno.garr...@gmx.de To: ICS support mailing twsocket@elists.org Sent: Thursday, February 10, 2011 3:32 PM Subject: Re: [twsocket] Proxy traversal error handling Francois PIETTE wrote: Some proxies just close or reset the connection if, for instance, the remote server is not listening or if Socks authentication fails for some _technical reason. It's my understanding that in such cases SessionConnected should be triggered with an error 0 before SessionClose, is that correct? Currently both Socks and HTTP-Tunnel code in TWSocket don't do that but only trigger SessionClose, even without an error in case of close (fin). Yes, normally in case of a connection cannot be established, OK. OnSessionConnected should be called with a non nul error argument and then OnSessionClosed with same argument. Currently I do not think so. With a proxy we have a special case, in case the connection to the proxy is established successfully we delay OnSessionConnected until we either passed thru or got some error response from the proxy. Now if the proxy silently resets or closes the connection without prior returning any error response while the tunnel is not established yet the component should pass a proxy-specific error code to OnSessionConnected and the true winsock error code to SessionClosed IMO. Why must the error code in SessionClosed be faked as well? Note that the true error code on SessionClosed in case above can WSAECONNRESET or zero respectively. -- 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 -- 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] HTTPServer sending 303
I am having trouble getting ICS sending out a 303 redirection. I copied the 404 answer code which works, but this code makes the client just spin its wheels. Nothing is requested from the client after this point. Tried with a 302 and get the same results. This comes at the end of the HttpServerPostedData event where other answers are sent from. What am I over looking? thanks Ed procedure tClientConn.Answer303(URL : String); var Body : String; begin Body := 'HTMLHEADTITLE303 See Other/TITLE/HEAD' + 'BODYH1303 See other/H1'; SendHeader(FVersion + ' 303 See Other' + #13#10 + 'Location: http://www.xxx.com' + URL + #13#10); SendStr(Body); end; -- 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
