Re: Sockets Beginreceive not working correctly.

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

I'm only sending the word "hello", the first time I step through the code, I
recieve the data, the second time, I don't. It seems like the line that has
the beginrecieve is ignored.


"Peter Duniho" <NpOeStPeAdM@xxxxxxxxxxxxxxxx> wrote in message
news:op.un2w69s08jd0ej@xxxxxxxxxxxxxxxxxxxxxxx
On Tue, 20 Jan 2009 15:19:16 -0800, David <nospam@xxxxxxxx> wrote:

I'm using Sockets to send a receive data. My issue is when I open up a
socket, I can send and receive data correctly the first try. Upon the
second try without closing anything, I send some data, but receive
nothing.

There are two likely possibilities:

-- By the time you get to stepping through the code, all of the data
you sent has been sent. In which case, it will all have been received by
your first receive (assuming the buffer's big enough).

-- By the time you get to stepping through the code, the second part
of your data hasn't yet been sent.

In either case, there's no reason to expect your callback method to be
executed.

I noticed as I step through the code, during the second receive, I
execute
the client.BeginReceive but the debugger goes to the next line without
going
into the callback function, as if that Client.BeginRecieve line isn't
there.
No errors occur.

BeginReceive() would not normally execute the callback in any case. The
normal use case involves BeginReceive() returning immediately, and your
callback being executed at some later time, when there's actually data to
be received.

Anyone have any ideas, what that maybe. Would I have some something
blocking
from the first receive?

Without a concise-but-complete code sample, it's impossible to say for
sure why your expectations are incorrect. However, suffice to say that
the likelihood of it actually being the case that "Beginreceive [sic] not
working correctly" is practically non-existent. You are surely doing
something wrong.

By the way, one thing I can see from your code that you're definitely
doing wrong is using a new Encoding instance each time you receive more
data. You should be calling GetDecoder() and using the one Decoder you
get each time you receive bytes, so that it can correctly deal with
multi-byte characters that might have gotten split up during transmission.

Pete


.

Relevant Pages

  • Re: Sockets Beginreceive not working correctly.
    ... -- By the time you get to stepping through the code, the second part of your data hasn't yet been sent. ... there's no reason to expect your callback method to be executed. ... BeginReceivewould not normally execute the callback in any case. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Sockets Beginreceive not working correctly.
    ... It seems like the line that has the beginrecieve is ignored. ... you don't need to wait after setting up the beginreceive call - the callback will be executed when the TCP/IP stack has data for your callback. ... BeginReceivewould not normally execute the callback in any case. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: [patch 1/7] Immediate Values - Architecture Independent Code
    ... static unsigned int stopmachine_num_threads; ... * help our sisters onto their CPUs. ... all the other CPUs will execute the callback concurrently. ...
    (Linux-Kernel)
  • Re: How can I tell if my Ribbon is visible?
    ... Depending on the performance cost of executing the callback, you could do this whenever your event gets triggered, but before you execute your parsing. ... The callback will be executed once your tab is brought into the foreground. ... You can do this approach with any of your controls and callbacks, there is no need to create a special one for it. ...
    (microsoft.public.office.developer.com.add_ins)
  • Re: In asynchronous model, IAsyncResult.AsyncWaitHandle signaled first, or AsyncCallback invoked fir
    ... The correct sequence should be ... because the callback function might wait on the ... Just because the WaitHandle gets set, that doesn't mean that the thread waiting on it will run immediately. ... Until that thread exhausts its quantum or hits some sort of wait state itself, the thread waiting on the WaitHandle still isn't going to execute. ...
    (microsoft.public.dotnet.languages.csharp)