473,574 Members | 3,182 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

TCP - Outstanding Begin Receives

It is possible to have an outstanding BeginReceive call when closing a
socket. There isn't a call from the IAsyncResult to cancel this if it hasn't
completed. This can be an issue when you are accepting a large number of
connections in a long running process.

First off, why isn't there a method for cancelling these requests?

Is there a work around that anyone knows about?

My state object that is referenced by the request is large, so I at least
try to cleanup this reference, but there is still an OS object that is queued
for this request that doesn't get freed.
Dec 22 '05 #1
7 1760
Async I/O will be canceled if the thread that initiated that I/O will exit.

This means if you're calling BeginReceive the thread that accepts incomming
connections - it will be sufficient to stop that thread.

Also if you will call Socket.Shutdown , the exception will be thrown in
EndReceive(...) or appropriate SocketError returned ( under .NET 2.0 )

--
Vadym Stetsyak aka Vadmyst
http://vadmyst.blogspot.com

"Larry Herbinaux" <La************ @discussions.mi crosoft.com> wrote in
message news:2A******** *************** ***********@mic rosoft.com...
It is possible to have an outstanding BeginReceive call when closing a
socket. There isn't a call from the IAsyncResult to cancel this if it
hasn't
completed. This can be an issue when you are accepting a large number of
connections in a long running process.

First off, why isn't there a method for cancelling these requests?

Is there a work around that anyone knows about?

My state object that is referenced by the request is large, so I at least
try to cleanup this reference, but there is still an OS object that is
queued
for this request that doesn't get freed.

Dec 22 '05 #2
Thanks Vadym,

On your first point, the async request is being performed in a thread pool
thread (e.g. when the AsyncAccept callback is called it is on a thread in the
thread pool and I immediately do a BeginRead within this thread), so this
thread never exits, right? I'm sure that the request is registered in the OS
and when an IOCompletionPor t is signaled, the callback runs on a thread in
the thread pool and this process starts all over again until we close the
socket.

Depending on who (client / server) and how the socket is closed, there still
could be an outstanding async receive request. We are using 1.1, so in your
second point I'm not sure it applies. A couple of questions on this:

1) If I do a close on the socket, will this cleanup any outstanding receive
/ send requests?

2) I am holding on to the IAsyncResult for the outstanding receive and send
(in my wrapper socket class), so I could use the EndReceive prior to closing
the socket. The issue here is that if for some reason the remote (client
socket) is not closed, this call will block (at least that's what MSDN
states). I think 99% of the time the client socket will be closed, but I
also have a cleanup process that checks if we haven't had read / write data
from the socket for a certain amount of time, then I have to do a hard close
from the server...would the EndReceive block in this case?

"Vadym Stetsyak" wrote:
Async I/O will be canceled if the thread that initiated that I/O will exit.

This means if you're calling BeginReceive the thread that accepts incomming
connections - it will be sufficient to stop that thread.

Also if you will call Socket.Shutdown , the exception will be thrown in
EndReceive(...) or appropriate SocketError returned ( under .NET 2.0 )

--
Vadym Stetsyak aka Vadmyst
http://vadmyst.blogspot.com

"Larry Herbinaux" <La************ @discussions.mi crosoft.com> wrote in
message news:2A******** *************** ***********@mic rosoft.com...
It is possible to have an outstanding BeginReceive call when closing a
socket. There isn't a call from the IAsyncResult to cancel this if it
hasn't
completed. This can be an issue when you are accepting a large number of
connections in a long running process.

First off, why isn't there a method for cancelling these requests?

Is there a work around that anyone knows about?

My state object that is referenced by the request is large, so I at least
try to cleanup this reference, but there is still an OS object that is
queued
for this request that doesn't get freed.


Dec 22 '05 #3
> 1) If I do a close on the socket, will this cleanup any outstanding
receive
/ send requests?
Yes
2) I am holding on to the IAsyncResult for the outstanding receive and
send
(in my wrapper socket class), so I could use the EndReceive prior to
closing
the socket. The issue here is that if for some reason the remote (client
socket) is not closed, this call will block (at least that's what MSDN
states). I think 99% of the time the client socket will be closed, but I
also have a cleanup process that checks if we haven't had read / write
data
from the socket for a certain amount of time, then I have to do a hard
close
from the server...would the EndReceive block in this case?
EndReceive will block for timeout, of Socket keepalive option was not
specified.
If server will close the socket EndReceive in the client side will throw an
exception, or
return 0 bytes, indicating graceful connection close ( more probable ).

--
Vadym Stetsyak aka Vadmyst
http://vadmyst.blogspot.com

"Larry Herbinaux" <La************ @discussions.mi crosoft.com> wrote in
message news:71******** *************** ***********@mic rosoft.com... Thanks Vadym,

On your first point, the async request is being performed in a thread pool
thread (e.g. when the AsyncAccept callback is called it is on a thread in
the
thread pool and I immediately do a BeginRead within this thread), so this
thread never exits, right? I'm sure that the request is registered in the
OS
and when an IOCompletionPor t is signaled, the callback runs on a thread in
the thread pool and this process starts all over again until we close the
socket.

Depending on who (client / server) and how the socket is closed, there
still
could be an outstanding async receive request. We are using 1.1, so in
your
second point I'm not sure it applies. A couple of questions on this:

1) If I do a close on the socket, will this cleanup any outstanding
receive
/ send requests?

2) I am holding on to the IAsyncResult for the outstanding receive and
send
(in my wrapper socket class), so I could use the EndReceive prior to
closing
the socket. The issue here is that if for some reason the remote (client
socket) is not closed, this call will block (at least that's what MSDN
states). I think 99% of the time the client socket will be closed, but I
also have a cleanup process that checks if we haven't had read / write
data
from the socket for a certain amount of time, then I have to do a hard
close
from the server...would the EndReceive block in this case?

"Vadym Stetsyak" wrote:
Async I/O will be canceled if the thread that initiated that I/O will
exit.

This means if you're calling BeginReceive the thread that accepts
incomming
connections - it will be sufficient to stop that thread.

Also if you will call Socket.Shutdown , the exception will be thrown in
EndReceive(...) or appropriate SocketError returned ( under .NET 2.0 )

--
Vadym Stetsyak aka Vadmyst
http://vadmyst.blogspot.com

"Larry Herbinaux" <La************ @discussions.mi crosoft.com> wrote in
message news:2A******** *************** ***********@mic rosoft.com...
> It is possible to have an outstanding BeginReceive call when closing a
> socket. There isn't a call from the IAsyncResult to cancel this if it
> hasn't
> completed. This can be an issue when you are accepting a large number
> of
> connections in a long running process.
>
> First off, why isn't there a method for cancelling these requests?
>
> Is there a work around that anyone knows about?
>
> My state object that is referenced by the request is large, so I at
> least
> try to cleanup this reference, but there is still an OS object that is
> queued
> for this request that doesn't get freed.


Dec 22 '05 #4
Thanks a lot this really helped. I just want to clarify that I understand
your response.

As for your answer to #1, if this is the case, then I don't have to worry
about the outstanding requests holding on to my state object, this should all
be garbage collected, right? Do you know the name of the structure that the
OS holds for these requests? I could use CLR Profiler to verify this, huh?

As for #2, I didn't know that there is a possibility of an exception being
thrown when closing the socket; I've always seen a count of 0 and do the
appropriate thing. In most cases, I do a shutdown of the send channel and
wait for the other socket to respond in a similar fashion before I shutdown
the receive channel. I don't like Microsoft's recommendation of shutting
down both channels because this causes an exception in most cases to be
thrown in the outstanding asynchronous receive request (previously, I handled
this but logged it and I don't like cluttering the log for this purpose).
The only time I do a shutdown of both and close is if the server recognizes a
connection that has been inactive for a period of time (e.g. physical line
was severed, etc.).

Thanks again for your input.

"Vadym Stetsyak" wrote:
1) If I do a close on the socket, will this cleanup any outstanding
receive
/ send requests?


Yes
2) I am holding on to the IAsyncResult for the outstanding receive and
send
(in my wrapper socket class), so I could use the EndReceive prior to
closing
the socket. The issue here is that if for some reason the remote (client
socket) is not closed, this call will block (at least that's what MSDN
states). I think 99% of the time the client socket will be closed, but I
also have a cleanup process that checks if we haven't had read / write
data
from the socket for a certain amount of time, then I have to do a hard
close
from the server...would the EndReceive block in this case?


EndReceive will block for timeout, of Socket keepalive option was not
specified.
If server will close the socket EndReceive in the client side will throw an
exception, or
return 0 bytes, indicating graceful connection close ( more probable ).

--
Vadym Stetsyak aka Vadmyst
http://vadmyst.blogspot.com

"Larry Herbinaux" <La************ @discussions.mi crosoft.com> wrote in
message news:71******** *************** ***********@mic rosoft.com...
Thanks Vadym,

On your first point, the async request is being performed in a thread pool
thread (e.g. when the AsyncAccept callback is called it is on a thread in
the
thread pool and I immediately do a BeginRead within this thread), so this
thread never exits, right? I'm sure that the request is registered in the
OS
and when an IOCompletionPor t is signaled, the callback runs on a thread in
the thread pool and this process starts all over again until we close the
socket.

Depending on who (client / server) and how the socket is closed, there
still
could be an outstanding async receive request. We are using 1.1, so in
your
second point I'm not sure it applies. A couple of questions on this:

1) If I do a close on the socket, will this cleanup any outstanding
receive
/ send requests?

2) I am holding on to the IAsyncResult for the outstanding receive and
send
(in my wrapper socket class), so I could use the EndReceive prior to
closing
the socket. The issue here is that if for some reason the remote (client
socket) is not closed, this call will block (at least that's what MSDN
states). I think 99% of the time the client socket will be closed, but I
also have a cleanup process that checks if we haven't had read / write
data
from the socket for a certain amount of time, then I have to do a hard
close
from the server...would the EndReceive block in this case?

"Vadym Stetsyak" wrote:
Async I/O will be canceled if the thread that initiated that I/O will
exit.

This means if you're calling BeginReceive the thread that accepts
incomming
connections - it will be sufficient to stop that thread.

Also if you will call Socket.Shutdown , the exception will be thrown in
EndReceive(...) or appropriate SocketError returned ( under .NET 2.0 )

--
Vadym Stetsyak aka Vadmyst
http://vadmyst.blogspot.com

"Larry Herbinaux" <La************ @discussions.mi crosoft.com> wrote in
message news:2A******** *************** ***********@mic rosoft.com...
> It is possible to have an outstanding BeginReceive call when closing a
> socket. There isn't a call from the IAsyncResult to cancel this if it
> hasn't
> completed. This can be an issue when you are accepting a large number
> of
> connections in a long running process.
>
> First off, why isn't there a method for cancelling these requests?
>
> Is there a work around that anyone knows about?
>
> My state object that is referenced by the request is large, so I at
> least
> try to cleanup this reference, but there is still an OS object that is
> queued
> for this request that doesn't get freed.


Dec 22 '05 #5
For #1

If there is no references to your state object then it will be GC-ed.

BeginReceive call is mapped to WSARecv(...). This is Winsock2 function. For
async io it uses
WSAOVERLAPPED structure. This structure holds the state, however, it holds a
pointer so you won't be able to see the object using it.

Yes, you can use CLR Profiler to verify how many state objects are there in
the memory, but for that you do not need any OS structures.

For #2

Yes, returting 0 is graceful shutdown, however world is not perfect, you may
expereience hardware problems ( on the wire, remote host crashed etc )

Using Socket.Shutdown with Both or Receive will cause an exception or socket
error ( in .NET 2.0 ).
From the doc about Shutdown
"Setting how to Receive specifies that subsequent calls to Receive are not
allowed"
You can use this SocketShudown options to control, the way how connection is
being closed ( with or without sending/receiving data after shutdown, but
before close )

--
Vadym Stetsyak aka Vadmyst
http://vadmyst.blogspot.com

"Larry Herbinaux" <La************ @discussions.mi crosoft.com> wrote in
message news:E4******** *************** ***********@mic rosoft.com...
Thanks a lot this really helped. I just want to clarify that I understand
your response.

As for your answer to #1, if this is the case, then I don't have to worry
about the outstanding requests holding on to my state object, this should
all
be garbage collected, right? Do you know the name of the structure that
the
OS holds for these requests? I could use CLR Profiler to verify this,
huh?

As for #2, I didn't know that there is a possibility of an exception being
thrown when closing the socket; I've always seen a count of 0 and do the
appropriate thing. In most cases, I do a shutdown of the send channel and
wait for the other socket to respond in a similar fashion before I
shutdown
the receive channel. I don't like Microsoft's recommendation of shutting
down both channels because this causes an exception in most cases to be
thrown in the outstanding asynchronous receive request (previously, I
handled
this but logged it and I don't like cluttering the log for this purpose).
The only time I do a shutdown of both and close is if the server
recognizes a
connection that has been inactive for a period of time (e.g. physical line
was severed, etc.).

Thanks again for your input.

"Vadym Stetsyak" wrote:
> 1) If I do a close on the socket, will this cleanup any outstanding
> receive
> / send requests?


Yes
> 2) I am holding on to the IAsyncResult for the outstanding receive and
> send
> (in my wrapper socket class), so I could use the EndReceive prior to
> closing
> the socket. The issue here is that if for some reason the remote
> (client
> socket) is not closed, this call will block (at least that's what MSDN
> states). I think 99% of the time the client socket will be closed, but
> I
> also have a cleanup process that checks if we haven't had read / write
> data
> from the socket for a certain amount of time, then I have to do a hard
> close
> from the server...would the EndReceive block in this case?


EndReceive will block for timeout, of Socket keepalive option was not
specified.
If server will close the socket EndReceive in the client side will throw
an
exception, or
return 0 bytes, indicating graceful connection close ( more probable ).

--
Vadym Stetsyak aka Vadmyst
http://vadmyst.blogspot.com

"Larry Herbinaux" <La************ @discussions.mi crosoft.com> wrote in
message news:71******** *************** ***********@mic rosoft.com...
> Thanks Vadym,
>
> On your first point, the async request is being performed in a thread
> pool
> thread (e.g. when the AsyncAccept callback is called it is on a thread
> in
> the
> thread pool and I immediately do a BeginRead within this thread), so
> this
> thread never exits, right? I'm sure that the request is registered in
> the
> OS
> and when an IOCompletionPor t is signaled, the callback runs on a thread
> in
> the thread pool and this process starts all over again until we close
> the
> socket.
>
> Depending on who (client / server) and how the socket is closed, there
> still
> could be an outstanding async receive request. We are using 1.1, so in
> your
> second point I'm not sure it applies. A couple of questions on this:
>
> 1) If I do a close on the socket, will this cleanup any outstanding
> receive
> / send requests?
>
> 2) I am holding on to the IAsyncResult for the outstanding receive and
> send
> (in my wrapper socket class), so I could use the EndReceive prior to
> closing
> the socket. The issue here is that if for some reason the remote
> (client
> socket) is not closed, this call will block (at least that's what MSDN
> states). I think 99% of the time the client socket will be closed, but
> I
> also have a cleanup process that checks if we haven't had read / write
> data
> from the socket for a certain amount of time, then I have to do a hard
> close
> from the server...would the EndReceive block in this case?
>
> "Vadym Stetsyak" wrote:
>
>> Async I/O will be canceled if the thread that initiated that I/O will
>> exit.
>>
>> This means if you're calling BeginReceive the thread that accepts
>> incomming
>> connections - it will be sufficient to stop that thread.
>>
>> Also if you will call Socket.Shutdown , the exception will be thrown in
>> EndReceive(...) or appropriate SocketError returned ( under .NET 2.0 )
>>
>> --
>> Vadym Stetsyak aka Vadmyst
>> http://vadmyst.blogspot.com
>>
>> "Larry Herbinaux" <La************ @discussions.mi crosoft.com> wrote in
>> message news:2A******** *************** ***********@mic rosoft.com...
>> > It is possible to have an outstanding BeginReceive call when closing
>> > a
>> > socket. There isn't a call from the IAsyncResult to cancel this if
>> > it
>> > hasn't
>> > completed. This can be an issue when you are accepting a large
>> > number
>> > of
>> > connections in a long running process.
>> >
>> > First off, why isn't there a method for cancelling these requests?
>> >
>> > Is there a work around that anyone knows about?
>> >
>> > My state object that is referenced by the request is large, so I at
>> > least
>> > try to cleanup this reference, but there is still an OS object that
>> > is
>> > queued
>> > for this request that doesn't get freed.
>>
>>
>>


Dec 23 '05 #6
Thanks Vadmyst,

I solved my issue and it actually didn't have anything to do with
Outstanding Begin Receives. I will explain after quickly responding to point
#2.

#2:
I'm glad that .Net 2.0 throws an exception if you Shutdown both or receive.
It's interesting that prior to 2.0, Microsoft recommended shutting down both,
but this does not make any sense because you wouldn't be able to receive the
close handshake from the client. Greath, thanks for that tidbit of
information. We have 2.0, but I am going to wait a bit before migrating to
production environment:->

My main issue is that my objects used during the connection were not being
GC'd. I thought I had modelled each reference in a simple application and it
should that memory should be released. The only other thing that could have
held on to it was a state object (which also held a refernce to my objects)
be held by the OS which would root everything. I was wrong about this
assumption and overlooked something that would have taken me a while to
figure out if it weren't for SciTech's Memory Profiler. What's really cool
about the profiler is that you can do differences between heap snapshots and
also it will show you were an object is rooted. It only took me five mitues.
If you haven't used it before, then I would recommend getting it. I will
explain my structures and then the problem.

TCPServer - This has a hashtable that holds TCPServerClient .

TCPServerClient - Wrapper Socket class for the socket communicating with
client. It holds a reference to TCPServer (for sending data and passing a
reference to itself when application wants to send data) and
IAppProtocolPro cessor.

IAppProtocolPro cessor - An application programmer creates a class that
implements the interface (OnAccept, OnReceive, OnDisconnect, OnTimeout).
When OnAccept is called, a reference to TCPServerClient is passed and the
implement class stores a refernce to it in order to Send data among other
things. This class also implements a static method based on the
CreateAppProtoc ol delegate. This delegate is passed into the TCPServer
constructor so that it can create an instance in the AcceptCallback.

So there is a circular reference between TCPServerClient and
IAppProtocolPro cessor, the TCPServerClient has a reference to TCPServer, and
the TCPServerClient instance is referenced in the TCPServer hashtable. When
I close a connection, I simply remove the TCPServerClient form the hashtable.
My first worry was that the refrence form TCPServerClient up to TCPServer
was causing the problem because TCPServer is long-standing. This wasn't the
issue at all and I successfully modelled it. My problem was that in the
TCPServerClient , the timer was holding a reference to the
IAppProtocolPro cessor's OnTimeout callback. During the connection close, I
stop the timer but do not remove the reference, and since this his an OS
resource it is rooted. It wouldn't have dawned on me to look there; thank
God for Memory Profiler tools (or actually, thank SciTech:->).

"Vadym Stetsyak" wrote:
For #1

If there is no references to your state object then it will be GC-ed.

BeginReceive call is mapped to WSARecv(...). This is Winsock2 function. For
async io it uses
WSAOVERLAPPED structure. This structure holds the state, however, it holds a
pointer so you won't be able to see the object using it.

Yes, you can use CLR Profiler to verify how many state objects are there in
the memory, but for that you do not need any OS structures.

For #2

Yes, returting 0 is graceful shutdown, however world is not perfect, you may
expereience hardware problems ( on the wire, remote host crashed etc )

Using Socket.Shutdown with Both or Receive will cause an exception or socket
error ( in .NET 2.0 ).
From the doc about Shutdown
"Setting how to Receive specifies that subsequent calls to Receive are not
allowed"
You can use this SocketShudown options to control, the way how connection is
being closed ( with or without sending/receiving data after shutdown, but
before close )

--
Vadym Stetsyak aka Vadmyst
http://vadmyst.blogspot.com

"Larry Herbinaux" <La************ @discussions.mi crosoft.com> wrote in
message news:E4******** *************** ***********@mic rosoft.com...
Thanks a lot this really helped. I just want to clarify that I understand
your response.

As for your answer to #1, if this is the case, then I don't have to worry
about the outstanding requests holding on to my state object, this should
all
be garbage collected, right? Do you know the name of the structure that
the
OS holds for these requests? I could use CLR Profiler to verify this,
huh?

As for #2, I didn't know that there is a possibility of an exception being
thrown when closing the socket; I've always seen a count of 0 and do the
appropriate thing. In most cases, I do a shutdown of the send channel and
wait for the other socket to respond in a similar fashion before I
shutdown
the receive channel. I don't like Microsoft's recommendation of shutting
down both channels because this causes an exception in most cases to be
thrown in the outstanding asynchronous receive request (previously, I
handled
this but logged it and I don't like cluttering the log for this purpose).
The only time I do a shutdown of both and close is if the server
recognizes a
connection that has been inactive for a period of time (e.g. physical line
was severed, etc.).

Thanks again for your input.

"Vadym Stetsyak" wrote:
> 1) If I do a close on the socket, will this cleanup any outstanding
> receive
> / send requests?

Yes

> 2) I am holding on to the IAsyncResult for the outstanding receive and
> send
> (in my wrapper socket class), so I could use the EndReceive prior to
> closing
> the socket. The issue here is that if for some reason the remote
> (client
> socket) is not closed, this call will block (at least that's what MSDN
> states). I think 99% of the time the client socket will be closed, but
> I
> also have a cleanup process that checks if we haven't had read / write
> data
> from the socket for a certain amount of time, then I have to do a hard
> close
> from the server...would the EndReceive block in this case?

EndReceive will block for timeout, of Socket keepalive option was not
specified.
If server will close the socket EndReceive in the client side will throw
an
exception, or
return 0 bytes, indicating graceful connection close ( more probable ).

--
Vadym Stetsyak aka Vadmyst
http://vadmyst.blogspot.com

"Larry Herbinaux" <La************ @discussions.mi crosoft.com> wrote in
message news:71******** *************** ***********@mic rosoft.com...
> Thanks Vadym,
>
> On your first point, the async request is being performed in a thread
> pool
> thread (e.g. when the AsyncAccept callback is called it is on a thread
> in
> the
> thread pool and I immediately do a BeginRead within this thread), so
> this
> thread never exits, right? I'm sure that the request is registered in
> the
> OS
> and when an IOCompletionPor t is signaled, the callback runs on a thread
> in
> the thread pool and this process starts all over again until we close
> the
> socket.
>
> Depending on who (client / server) and how the socket is closed, there
> still
> could be an outstanding async receive request. We are using 1.1, so in
> your
> second point I'm not sure it applies. A couple of questions on this:
>
> 1) If I do a close on the socket, will this cleanup any outstanding
> receive
> / send requests?
>
> 2) I am holding on to the IAsyncResult for the outstanding receive and
> send
> (in my wrapper socket class), so I could use the EndReceive prior to
> closing
> the socket. The issue here is that if for some reason the remote
> (client
> socket) is not closed, this call will block (at least that's what MSDN
> states). I think 99% of the time the client socket will be closed, but
> I
> also have a cleanup process that checks if we haven't had read / write
> data
> from the socket for a certain amount of time, then I have to do a hard
> close
> from the server...would the EndReceive block in this case?
>
> "Vadym Stetsyak" wrote:
>
>> Async I/O will be canceled if the thread that initiated that I/O will
>> exit.
>>
>> This means if you're calling BeginReceive the thread that accepts
>> incomming
>> connections - it will be sufficient to stop that thread.
>>
>> Also if you will call Socket.Shutdown , the exception will be thrown in
>> EndReceive(...) or appropriate SocketError returned ( under .NET 2.0 )
>>
>> --
>> Vadym Stetsyak aka Vadmyst
>> http://vadmyst.blogspot.com
>>
>> "Larry Herbinaux" <La************ @discussions.mi crosoft.com> wrote in
>> message news:2A******** *************** ***********@mic rosoft.com...
>> > It is possible to have an outstanding BeginReceive call when closing
>> > a
>> > socket. There isn't a call from the IAsyncResult to cancel this if
>> > it
>> > hasn't
>> > completed. This can be an issue when you are accepting a large
>> > number
>> > of
>> > connections in a long running process.
>> >
>> > First off, why isn't there a method for cancelling these requests?
>> >
>> > Is there a work around that anyone knows about?
>> >
>> > My state object that is referenced by the request is large, so I at
>> > least
>> > try to cleanup this reference, but there is still an OS object that
>> > is
>> > queued
>> > for this request that doesn't get freed.
>>
>>
>>


Dec 23 '05 #7
I'm glad you resolved your issues :8-)

--
Vadym Stetsyak aka Vadmyst
http://vadmyst.blogspot.com
Dec 24 '05 #8

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

1
1802
by: haref | last post by:
hi ng, what can i do in the following mail function, which hast 400 subscribers who are read from a database and to which the mails are send in a loop, when there are some adresses who are not reachable. My provider receives all the failure mails. is it possible to send the mail daemons ( failures ) to a special adress, so that the...
11
3220
by: snnn | last post by:
On the book <Generic Programming and the STL>( Matthew . H . Austern ),this function is defined as iterator set::begin() const. However, why should a const object returns a non-const iterator? Then, I found, in this book, the semantic of set::iterator is defined as same as set::const_iterator. Both of them must be const! I tried to read the...
2
6282
by: Brad D. | last post by:
In my secure database, I have the admins group and a DeptUser group. I am trying to set up a new user in the admins group and the DeptUser group. However, this new administrator receives the error 3033: You do not have the necessary permissions to use the 'qryViewLD' object. I am a member of admins and I do not get this message. I'm...
4
16010
by: Morten Overgaard | last post by:
Hi I'm listening on the SysLog port (514) through UDP. The problem is that I am not receiving anything nut I know that i get messages on the port. When I use KIWI to listen on the same port via UDP tons of messages arrive.. What am I'm doing wrong My code looks like the following... private UdpClient udpClient;
1
2190
by: Karl O. Pinc | last post by:
FYI, mostly. But I do have questions as to how to write code that will continue to work in subsequent postgresql versions. See code below. begintest() uses EXIT to exit a BEGIN block from within nested loops. No problem. begintest2() simplifies this, omitting the nested loops. Still no problem.
3
1466
by: joey.edelstein | last post by:
Hi, I created a .Net web service by compiling a WSDL file with "WSDL /server" then implementing the resulting abstract class. Relevant sections of the WSDL are a the bottom of this message. When I call the web service using SOAP Scope or by code, no matter what values I give for for optional parameters it receives a 0 length array for the...
89
3801
by: Homer J Simpson | last post by:
I am coming to the conclusion that Microsoft doesn't want you to use VB ..Net, based on my experiences. I've downloaded the Express version and signed up for various support options etc. At every turn I have found the whole experience frustrating, involving endless non functioning software, broken links, incomprehensible and irrelevant...
0
1860
by: foahchon | last post by:
Hi, I'm trying to write a receive loop in my socket class that will receive what data is in the buffer, call an event to let the user know that there's new data, and then receive the rest of the data. It kinda almost works; it receives much of the data, but seems to miss the last packet or two. Here is the code in the loop: private...
4
2123
by: hex_05 | last post by:
In java, I always use common loging and log4j for loging. Is there any outstanding log library in C/C++? ---Thank for you replying
0
7758
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language...
0
8100
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. ...
1
7856
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For...
0
8137
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the...
1
5651
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes...
0
3773
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in...
0
3793
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
1
2270
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
1
1369
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.