Re: [twsocket] Hang in TIcsWndControl.ProcessMessages
Looks like you try to workaround the asynchronous nature of TWSocket which were a bad idea. Where do you call this and what do you want to achieve? Waiting for all sockets to close cleanly may be necessary before terminating an application, to ensure continuously streamed data is not lost. I do much the same thing in my ComCap application. 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] TWSocket.Close() blocks on certainmachines aftersending UDP
On 7/13/2011 7:23, Francois PIETTE wrote: AFAIR the workaround was to do your own ARP request first in order to check whether the destination exists or not, utilizing the IP Helper API. Yes, that what I did. How can I confirm that this is what's happening with me? In my case, the blocking was occuring in the main thread. TO see it it was then easy: using the mouse, I moved continuously the form in small circles. When blocked, the application don't paint the form and the window was stuck. Then using WireShark I was able to see that the blocking was when ARP requests were sent to non existant address. I just did the same test and can confirm this is the case. The call to closesocket() is blocking until all 3 arp requests have been sent. Now the interesting part is that on another Windows 7 machine the call to closesocket() is not blocking. When looking with wireshark I see that the 3 arp requests are sent, but closesocket() simply does not wait for them. I did a compare of winsock.dll and ws2_32.dll from both machines, and they are identical. Does anybody have a good idea how to search for the cause for different behavior, or have an idea where it could originate from? Could it be something related to the chipset? Thanks all! Merijn -- 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.Close() blocks on certain machines after sending UDP
On 7/13/2011 12:13, Arno Garrels wrote: Merijn Bosma wrote: Now the interesting part is that on another Windows 7 machine the call to closesocket() is not blocking. When looking with wireshark I see that the 3 arp requests are sent, but closesocket() simply does not wait for them. I'm happy you see the same behaviour as I do. I did a compare of winsock.dll and ws2_32.dll from both machines, and they are identical. Does anybody have a good idea how to search for the cause for different behavior, or have an idea where it could originate from? Could it be something related to the chipset? I don't think it is a hardware issue. It is likely a software issue. One of the layer between winsock and the network card has a bug. That is why you see it on one computer and not another. Determining which layer is faulty will be a difficult task ! I don't know what to say to help you :-( I agree that it's not a hardware issue. Do you know what layers are there approximately? I've already ruled out the driver of the NIC itself. I was mentioning the chipset since there is also software applicable (driver of the chipset). Also strange is that I have more machines of same brand and model, which do not show the same behavior. It's a nice mystery :) Indeed it is. Are all systems fully patched? Latest services packs and hot fixes? Yes, fully patched. Meanwhile, the mainboard has been replaced, other board with different revisions of north and south bridge. I'm doing a full reinstall now. I don't expect much of it, it's just for completeness sake :\ Merijn -- 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.Close() blocks on certainmachines aftersending UDP
I don't think it is a hardware issue. It is likely a software issue. One of the layer between winsock and the network card has a bug. That is why you see it on one computer and not another. Determining which layer is faulty will be a difficult task ! I don't know what to say to help you :-( I agree that it's not a hardware issue. Do you know what layers are there approximately? I've already ruled out the driver of the NIC itself. I was mentioning the chipset since there is also software applicable (driver of the chipset). Also strange is that I have more machines of same brand and model, which do not show the same behavior. It's a nice mystery :) Having a machine with same brand and model is a chance because you can compare both. Of course if they have different stories, it is likely they have not so comparable software installed. There are a number of layers. The most probable culprit is a layer which understand the protocol. Probably the layers at packet level is not the cause otherwise there would be blocking for all protocols. It is interesting to read Windows® Internals (http://fresh.amazon.com/product?asin=0735625301). The chapter 12 explain the networking. Figure 12.2 page 1005 is very intersting: OSI Model and Windows Networking Components http://book.51cto.com/art/200911/160900.htm. Text is at: http://images.51cto.com/files/uploadimg/20091104/1038000.jpg I suggest to anyone to buy this book. It is very very interesting to understand how Windows works ! I'll keep the list posted if I find more information myself. Thanks a lot. This kind of information is very useful. -- 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] TWSocket.Close() blocks on certainmachines aftersending UDP
On 7/13/2011 13:17, Francois PIETTE wrote: I agree that it's not a hardware issue. Do you know what layers are there approximately? I've already ruled out the driver of the NIC itself. I was mentioning the chipset since there is also software applicable (driver of the chipset). Also strange is that I have more machines of same brand and model, which do not show the same behavior. It's a nice mystery :) Having a machine with same brand and model is a chance because you can compare both. Of course if they have different stories, it is likely they have not so comparable software installed. There are a number of layers. The most probable culprit is a layer which understand the protocol. Probably the layers at packet level is not the cause otherwise there would be blocking for all protocols. It is interesting to read Windows® Internals (http://fresh.amazon.com/product?asin=0735625301). The chapter 12 explain the networking. Figure 12.2 page 1005 is very intersting: OSI Model and Windows Networking Components http://book.51cto.com/art/200911/160900.htm. Text is at: http://images.51cto.com/files/uploadimg/20091104/1038000.jpg I suggest to anyone to buy this book. It is very very interesting to understand how Windows works ! I'll keep the list posted if I find more information myself. Thanks a lot. This kind of information is very useful. Thanks for the links, it's an interesting read. What still goes beyond me though, is that all I see in the diagram seems to be hardware independent stuff, so how could it ever happen that it behaves different on different machines? Maybe I can do a more in depth comparison of the different libraries used in windows, not just winsock.dll and ws2_32.dll Meanwhile I found out that even though the working machines are same brand and model, the casing differs. Not working is Small Form Factor, working is Mini Tower. I'm going to check with the manufacturer what the difference in hardware is between the two. Merijn -- 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.Close() blocks on certainmachines aftersending UDP
Thanks for the links, it's an interesting read. What still goes beyond me though, is that all I see in the diagram seems to be hardware independent stuff, so how could it ever happen that it behaves different on different machines? That's the point: IMO the issue comes from the software which is likely to be different on each system because different applications are installed and service pack level or patch order, or whetever is different. if you have a brand new PC, two things are interesting: 1) Do a full backup on the offending backup and do a restore on the new hardware. If problem is gone then the hardware is the culprit. If the problem persists, then the software is the culprit and go to the second option 2) Reinstalling from scratch, with original media and see if it occurs. -- 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] TWSocket.Close() blocks on certainmachines aftersending UDP
On 7/13/2011 15:07, Francois PIETTE wrote: Thanks for the links, it's an interesting read. What still goes beyond me though, is that all I see in the diagram seems to be hardware independent stuff, so how could it ever happen that it behaves different on different machines? That's the point: IMO the issue comes from the software which is likely to be different on each system because different applications are installed and service pack level or patch order, or whetever is different. if you have a brand new PC, two things are interesting: 1) Do a full backup on the offending backup and do a restore on the new hardware. If problem is gone then the hardware is the culprit. If the problem persists, then the software is the culprit and go to the second option 2) Reinstalling from scratch, with original media and see if it occurs. Unfortunately, this is not an achievable option atm. The machines which do work are installed at a client in Cardiff (UK). I have two machines here, and both don't work, even after reinstall. Currently in debate with the manufacturer. It seems the only difference between the two machines is the layout of the components on the mainboard, chipset, NIC and other hardware (should be) identical. Stupid thing is, from logical point of view, you can rule out both hardware and software, hardware cause it's been either fully replaced (mainboard) or does work in another machine (NIC). Software because the same software does work on another machine, and stays persistent after full/clean install (original media). -- 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.Close() blocks on certainmachines aftersending UDP
On 7/13/2011 15:43, Merijn Bosma wrote: On 7/13/2011 15:07, Francois PIETTE wrote: Thanks for the links, it's an interesting read. What still goes beyond me though, is that all I see in the diagram seems to be hardware independent stuff, so how could it ever happen that it behaves different on different machines? That's the point: IMO the issue comes from the software which is likely to be different on each system because different applications are installed and service pack level or patch order, or whetever is different. if you have a brand new PC, two things are interesting: 1) Do a full backup on the offending backup and do a restore on the new hardware. If problem is gone then the hardware is the culprit. If the problem persists, then the software is the culprit and go to the second option 2) Reinstalling from scratch, with original media and see if it occurs. Unfortunately, this is not an achievable option atm. The machines which do work are installed at a client in Cardiff (UK). I have two machines here, and both don't work, even after reinstall. Currently in debate with the manufacturer. It seems the only difference between the two machines is the layout of the components on the mainboard, chipset, NIC and other hardware (should be) identical. Stupid thing is, from logical point of view, you can rule out both hardware and software, hardware cause it's been either fully replaced (mainboard) or does work in another machine (NIC). Software because the same software does work on another machine, and stays persistent after full/clean install (original media). -- 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 I just made a nice discovery. I found out that I had another machine (same model, but mini tower) sitting here somewhere. I checked, and the problem does not show there. So I took the hard drive from the not working one and put it in the working one and it booted nicely (since hardware is identical). The problem moved too! So I have a hard drive, which contains a super fresh copy of Windows 7 which does not work, and another hard drive with an older Windows 7 installation which does work. Any tips or question what to compare or test? Merijn -- 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.Close() blocks on certainmachines aftersending UDP
I just made a nice discovery. I found out that I had another machine (same model, but mini tower) sitting here somewhere. I checked, and the problem does not show there. So I took the hard drive from the not working one and put it in the working one and it booted nicely (since hardware is identical). The problem moved too! So I have a hard drive, which contains a super fresh copy of Windows 7 which does not work, and another hard drive with an older Windows 7 installation which does work. This confirm what I said before: the problem comes from a software installed on the not working computer, not from the hardware. It is likely a difference in some driver. Any tips or question what to compare or test? First do an image of the working installation so that you can come back later to it after testing ! Then on the working machine do a windows update, and an update of evreything you can think off and check if it becomes a not working installation. If it does, then you have to find out exactly which update break the operation. MsInfo32 could be an help to comprae both computers. The running tasks list gives the version number of each module. You can see if they are the same or not. -- 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] Hang in TIcsWndControl.ProcessMessages
Angus Robertson - Magenta Systems Ltd wrote: Waiting for all sockets to close cleanly may be necessary before terminating an application, to ensure continuously streamed data is not lost. I do not see a reason why one must wait in a loop processing messages with calls to sleep()in order to achieve that, that's often a hint to bad design and should be avoided. I would not use sleep in such a loop, but if Windows is trying to close a service to reboot, you do need to loop for a few seconds while blocking the close down request. Indeed that would be a case. However a call to ShutDown(SD_BOTH) at that moment would likely raise a socket error at once if any subsequent attempt is made to send or receive something. -- 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
[twsocket] Terminal Size Scaling
Greetings.. I have been using the ICS package for a few weeks now and find it very nice to use. I have an old application that was passed to me to maintain... (aka, you are the support... we lost the source, good luck) Well up until recently things went well.. to a point. Now alot of changes are needed for a new system platform.. problem is, source got lost years ago.. many years ago.. The person who wrote it, no longer with company (many years) and the source has been long gone. It was a VT100 terminal client app for an internal service of ours. Plus it had many other features built into it, not just the terminal. One thing it had was the terminal could do was scale the fonts/ect when form resize.. so if made it full screen mode... it would do whatever and fonts looked nice and took up the whole screen. With ICS, it looks like this is doable.. CharWidth, LineZoom, CharZoom, LineHeight, FontSize, ect... Well I can only make it work if I use the edit options and manually dink with these until it works.. then if i resize the form, do it all over again. Change the font size to be smaller or bigger, and tweak each other property until all is good. For the end user, that wont be acceptable. Is there any better way to calculate the proper font size to use, and change all the other properties to make it so when the end user resizes the form, it will scale right? I've been banging my head on this for days, and can only get half working and ugly results. Thanks! -Steven -- 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] Terminal Size Scaling
Well I can only make it work if I use the edit options and manually dink with these until it works.. then if i resize the form, do it all over again. Change the font size to be smaller or bigger, and tweak each other property until all is good. For the end user, that wont be acceptable. Is there any better way to calculate the proper font size to use, and change all the other properties to make it so when the end user resizes the form, it will scale right? Use the OnResize event to calculate the chawidth and other parameters so that it fits well given the form size. At first it is simple computation. -- 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
