Re: [twsocket] UDP receive issue from a Windows service
François This could sound silly.. but is your Firewall active? We have a service application that receives UDP packets and we only have issues when windows firewall is active Eric -Mensagem Original- From: Francois PIETTE Sent: Monday, April 18, 2011 4:47 AM To: twsocket@elists.org Subject: [twsocket] UDP receive issue from a Windows service Hi ! I have a strange problem: in a windows service and using UDP, the service do not receive UDP datagram. Trying to debug this problem, I attach Delphi debugger to the running service and suddenly it starts receiving the UDP datagrams ! Actually the service is a dual mode service/app console and it works perfectly well as a console application (and also as a service when a debugger is attached). Any idea bout what could be wrong ? Probably a permission issue. It makes use of the default local system account used for services. Tested on Vista Ultimate 32 bits. -- 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] UDP receive issue from a Windows service
While testing, I also had during some time FD_READ triggered but ReceiveFrom returning -1. Isn't that quite common, if those are WSAEWOULDBLOCK errors? As far as I know, not so much. I saw is returning -1 during 4 seconds which is the timeout time in my appication. -- 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] UDP receive issue from a Windows service
Francois PIETTE wrote: >>> GDisplayProc is assigned a routine which output the message to the >>> console window and to the log file and which is used all over the >>> application. >>> >>> Guess what ? It works ! >>> This is not satisfying since the log file is full of unwanted >>> messages and this probably only hides the real problem. >> >> Does that mean notification from winsock works however the call to >> ReceiveFrom fails or doesn't return data? >> >> Or does it receive data with this extra logging? > > It receive data. Then I would search for a bug in the service/thread code. > While testing, I also had during some time FD_READ triggered but > ReceiveFrom returning -1. Isn't that quite common, if those are WSAEWOULDBLOCK errors? -- 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] UDP receive issue from a Windows service
GDisplayProc is assigned a routine which output the message to the console window and to the log file and which is used all over the application. Guess what ? It works ! This is not satisfying since the log file is full of unwanted messages and this probably only hides the real problem. Does that mean notification from winsock works however the call to ReceiveFrom fails or doesn't return data? Or does it receive data with this extra logging? It receive data. While testing, I also had during some time FD_READ triggered but ReceiveFrom returning -1. -- francois.pie...@overbyte.be 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] UDP receive issue from a Windows service
Surely, an attached debugger is going to use some CPU time, however small even if nothing triggers it, therefore, the debugged program cycle timing will change somehow, however small. Plus, however the debugger works, it could be forcing some other process (in the kernel) to do it's job more often, so keeping something up-to-date, that might otherwise slip a bit without that constant poking. I've also seen similar things (with other high speed I/O) in the past, it's 99% of the time, a timing problem. Somethings on the ragged edge, and any attached process (Debugger or ???) just helps that little bit by sneeking in a few extra nS somewhere. Multi core CPU's or HyperThreading seem to provoke this sort of mayhem more than most.. Can you dedicate your program to one core, and one core only? You did say TCP works OK, the extra overhead of that stack probably add's some time, and/or forces some data table updating, helping things too. Remember, Windows is not a real time system. Plus, it's not entirely unknown for MS to do things in not quite the right way. (As the rest of the world sees it anyway...) It could of course, be "something completely different", to quote Monty Python... I'll get me coat.. Dave B. > -Original Message- > From: Francois PIETTE [mailto:francois.pie...@skynet.be] > > > I think that if you consider what I suggested before, might > help you... > > It maybe has to do with extra process time the debugger gives > > Thanks for insisting. > > Which extra process time do you mean ? The debugger has just > to be attached. > No need to set any breakpoint nor single step. Just attach. > IMO, when a debugger is attached, the process is not slowed down. > > I would also add that there is definetely no CPU time issue, > nor network I/O issue with the application. Every second, it > send a single UDP datagram (A SNMP get request) and expect a > single UDP datagram (A SNMP get reply). A single socket is > used for both send and receive and datagram fits in winsock > receive buffer. > > -- > francois.pie...@overbyte.be > 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] UDP receive issue from a Windows service
Francois PIETTE wrote: > GDisplayProc is assigned a routine which output the message to the > console window and to the log file and which is used all over the > application. > > Guess what ? It works ! > This is not satisfying since the log file is full of unwanted > messages and this probably only hides the real problem. Does that mean notification from winsock works however the call to ReceiveFrom fails or doesn't return data? Or does it receive data with this extra logging? -- 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] UDP receive issue from a Windows service
Hi Francois, > A dual mode service is an application which detect if it run as a > service I understeand. I did the same concept years ago -- mvg, Wilfried http://www.mestdagh.biz http://www.comfortsoftware.be http://www.expertsoftware.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] UDP receive issue from a Windows service
Actually the service is a dual mode service/app console and it works perfectly well as a console application (and also as a service when a debugger is attached). I do not understand the 'dual mode' but could that be a reason? A dual mode service is an application which detect if it run as a service application or as a normal console application and take appropriate action according to the context. This is very handy for debugging. What happens if you put your application into 1 object (no console interaction), then create/run it in a console application then create/run it in a NT service application? This require a lot of work. I will do if I can't manage to make it work in dualmode. -- francois.pie...@overbyte.be 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] UDP receive issue from a Windows service
Seriously, what happens if you run the console application as a service with my NT Wrapper http://www.duodata.de/ntwrapper/? It will surely not work because my code for dual mode will be fooled, thinking it is a service application while it is not. If that works I guess the problem can be found in your service code, assuming that you neither use the Delphi service framework nor my DDService (http://www.duodata.de/misc/delphi/DDService.zip). I use my own code I wrote years ago. I use it in several applications (but none with UDP until now) with no problem. I have tryed something new and simple: I derived a new class from TWSocket and overriden TriggerDataAvailable. My idea was to know if it was triggered or not. Here is the code: type TDebugWSocket = class(TWSocket) protected functionTriggerDataAvailable(Error : Word) : Boolean; override; end; var GDisplayProc : procedure (const Msg : String) of object = nil; function TDebugWSocket.TriggerDataAvailable(Error: Word): Boolean; begin if Assigned(GDisplayProc) then GDisplayProc('TriggerDataAvailable'); Result := inherited TriggerDataAvailable(Error); end; GDisplayProc is assigned a routine which output the message to the console window and to the log file and which is used all over the application. Guess what ? It works ! This is not satisfying since the log file is full of unwanted messages and this probably only hides the real problem. -- francois.pie...@overbyte.be 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] UDP receive issue from a Windows service
Hi Francois, > Actually the service is a dual mode service/app console and it works > perfectly well as a console application (and also as a service when a > debugger is attached). I do not understand the 'dual mode' but could that be a reason? What happens if you put your application into 1 object (no console interaction), then create/run it in a console application then create/run it in a NT service application? -- mvg, Wilfried http://www.mestdagh.biz http://www.comfortsoftware.be http://www.expertsoftware.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] UDP receive issue from a Windows service
Arno Garrels wrote: > Francois PIETTE wrote: >>> Maybe when you use the debugger then the application run >>> undeer a different user? >> >> I start the service which starts sending his UDP datagrams (This is a >> SNMP client) and waiting for UDP response which never comes. Then I >> attach the debugger to the running service process and suddenly the >> UDP datagrams are coming in. > > Sounds like a Microsoft innovation preventing too many bug reports ;) Seriously, what happens if you run the console application as a service with my NT Wrapper http://www.duodata.de/ntwrapper/? If that works I guess the problem can be found in your service code, assuming that you neither use the Delphi service framework nor my DDService (http://www.duodata.de/misc/delphi/DDService.zip). -- 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] UDP receive issue from a Windows service
Francois PIETTE wrote: >> Maybe when you use the debugger then the application run >> undeer a different user? > > I start the service which starts sending his UDP datagrams (This is a > SNMP client) and waiting for UDP response which never comes. Then I > attach the debugger to the running service process and suddenly the > UDP datagrams are coming in. Sounds like a Microsoft innovation preventing too many bug reports ;) -- 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] UDP receive issue from a Windows service
When the debugger is attached is it exactly the same like when it's not attached for the program being executed ? I would say no since my application is working. But I would say it doesn't change the time required to do domething. OK then, my idea was that it's different. Actually I work with some external hardware devices (USB / serial connected) that sometimes in the past performed like in the reported problem and the solution was to give some more available time to the program with Application.ProcessMessages. But when the debugger was attached, this solution was not needed and it always worked fine. Anyway, my approach for the specific problem reported is more generic, not dealing at winsock level. OK, thanks anyway. -- francois.pie...@overbyte.be 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] UDP receive issue from a Windows service
On 18/4/2011 5:35 μμ, Francois PIETTE wrote: I think that if you consider what I suggested before, might help you... It maybe has to do with extra process time the debugger gives Thanks for insisting. Which extra process time do you mean ? The debugger has just to be attached. No need to set any breakpoint nor single step. Just attach. IMO, when a debugger is attached, the process is not slowed down. I would also add that there is definetely no CPU time issue, nor network I/O issue with the application. Every second, it send a single UDP datagram (A SNMP get request) and expect a single UDP datagram (A SNMP get reply). A single socket is used for both send and receive and datagram fits in winsock receive buffer. When the debugger is attached is it exactly the same like when it's not attached for the program being executed ? OK then, my idea was that it's different. Actually I work with some external hardware devices (USB / serial connected) that sometimes in the past performed like in the reported problem and the solution was to give some more available time to the program with Application.ProcessMessages. But when the debugger was attached, this solution was not needed and it always worked fine. Anyway, my approach for the specific problem reported is more generic, not dealing at winsock level. -- 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] UDP receive issue from a Windows service
I think that if you consider what I suggested before, might help you... It maybe has to do with extra process time the debugger gives Thanks for insisting. Which extra process time do you mean ? The debugger has just to be attached. No need to set any breakpoint nor single step. Just attach. IMO, when a debugger is attached, the process is not slowed down. I would also add that there is definetely no CPU time issue, nor network I/O issue with the application. Every second, it send a single UDP datagram (A SNMP get request) and expect a single UDP datagram (A SNMP get reply). A single socket is used for both send and receive and datagram fits in winsock receive buffer. -- francois.pie...@overbyte.be 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] UDP receive issue from a Windows service
Maybe when you use the debugger then the application run undeer a different user? I start the service which starts sending his UDP datagrams (This is a SNMP client) and waiting for UDP response which never comes. Then I attach the debugger to the running service process and suddenly the UDP datagrams are coming in. -- francois.pie...@overbyte.be 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] UDP receive issue from a Windows service
On 18/4/2011 5:12 μμ, Arno Garrels wrote: Maurizio Lotauro wrote: Maybe when you use the debugger then the application run undeer a different user? Not when the debugger is attached to a running process. If the debugger spawns the process to be debugged with CreateProcess then that might happen. I think that if you consider what I suggested before, might help you... It maybe has to do with extra process time the debugger gives -- 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] UDP receive issue from a Windows service
Maurizio Lotauro wrote: > Maybe when you use the debugger then the application run undeer a > different user? Not when the debugger is attached to a running process. If the debugger spawns the process to be debugged with CreateProcess then that might happen. -- 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] UDP receive issue from a Windows service
Maybe when you use the debugger then the application run undeer a different user? 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
Re: [twsocket] UDP receive issue from a Windows service
> *Subject:* Re: [twsocket] UDP receive issue from a Windows service > The code for the service is the code I already used in other > application which works fine (using TCP altough). I have UDP listen sockets in my ComCap application, running as a service, sucking in syslogs on port 514 24/7 from my firewalls on three servers, including 2008 which is the same as Vista. I have seen problems sending UDP, probably using a fixed port which I do sometimes to identify multiple UDP streams from the same server, but am planning on trying the ReuseAddr feature. 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] UDP receive issue from a Windows service
I had a similar experience in the past, not with ICS components but generally working on a completely different project. When project was running normally at some point did not work but when attaching a debugger then it would work. The problem at that situation was that the program needed some time to be given for some external operations, so if a debugger was attached or a sleep was introduced or a "Application.Processmessages" command was introduced, then it could work. I don't know if this solves the issue at your situation, but maybe it helps. Good luck. Thanks for suggestion, but I think this doesn't apply in my case. -- francois.pie...@overbyte.be 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] UDP receive issue from a Windows service
On 18/4/2011 2:34 μμ, Francois PIETTE wrote: No idea, but that can't be a permission issue IMO. Receiving datagrams in a service running as system works fine. Also attaching a debugger doesn't change security context of the debugee. What happens is that a new thread is created in the process being debugged, maybe there's some issue with your multi-threading? Maybe, but then why attaching a debugger would make things suddently work ? I really don't know what to do since attaching a debugger solve the issue. This really puzzles me ! The code for the service is the code I already used in other application which works fine (using TCP altough). I had a similar experience in the past, not with ICS components but generally working on a completely different project. When project was running normally at some point did not work but when attaching a debugger then it would work. The problem at that situation was that the program needed some time to be given for some external operations, so if a debugger was attached or a sleep was introduced or a "Application.Processmessages" command was introduced, then it could work. I don't know if this solves the issue at your situation, but maybe it helps. Good luck. -- 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] UDP receive issue from a Windows service
No idea, but that can't be a permission issue IMO. Receiving datagrams in a service running as system works fine. Also attaching a debugger doesn't change security context of the debugee. What happens is that a new thread is created in the process being debugged, maybe there's some issue with your multi-threading? Maybe, but then why attaching a debugger would make things suddently work ? I really don't know what to do since attaching a debugger solve the issue. This really puzzles me ! The code for the service is the code I already used in other application which works fine (using TCP altough). -- francois.pie...@overbyte.be 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] UDP receive issue from a Windows service
Hello Francois, > Hi ! > > I have a strange problem: in a windows service and using UDP, the > service do not receive UDP datagram. Trying to debug this problem, I > attach Delphi debugger to the running service and suddenly it starts > receiving the UDP datagrams ! > > Actually the service is a dual mode service/app console and it works > perfectly well as a console application (and also as a service when a > debugger is attached). > > Any idea bout what could be wrong ? Probably a permission issue. It > makes use of the default local system account used for services. > Tested on Vista Ultimate 32 bits. No idea, but that can't be a permission issue IMO. Receiving datagrams in a service running as system works fine. Also attaching a debugger doesn't change security context of the debugee. What happens is that a new thread is created in the process being debugged, maybe there's some issue with your multi-threading? -- Arno > > -- > 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] UDP receive issue from a Windows service
Hi ! I have a strange problem: in a windows service and using UDP, the service do not receive UDP datagram. Trying to debug this problem, I attach Delphi debugger to the running service and suddenly it starts receiving the UDP datagrams ! Actually the service is a dual mode service/app console and it works perfectly well as a console application (and also as a service when a debugger is attached). Any idea bout what could be wrong ? Probably a permission issue. It makes use of the default local system account used for services. Tested on Vista Ultimate 32 bits. -- 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