My_CSockets::OnReceive(int nErrorCode){ delete this;} /* stupid or smart? */ - Programmer

This is a discussion on My_CSockets::OnReceive(int nErrorCode){ delete this;} /* stupid or smart? */ - Programmer ; Hello everyone, This is my first time posting, up until now i've only used google to seach I'm creating a multiplayer minesweeper game in Windows, so I have been reading up on CSockets. I am begining to have a grasp ...

+ Reply to Thread
Results 1 to 17 of 17

Thread: My_CSockets::OnReceive(int nErrorCode){ delete this;} /* stupid or smart? */

  1. My_CSockets::OnReceive(int nErrorCode){ delete this;} /* stupid or smart? */

    Hello everyone,

    This is my first time posting, up until now i've only used google to seach


    I'm creating a multiplayer minesweeper game in Windows, so I have been
    reading up on CSockets. I am begining to have a grasp on them, but I have
    this one query.

    If a socket some data comes along that isnt part of my protocol, I want to
    remove the close the socket and delete it. The main question is on a
    OnReceive call can you tell the socket to delete itself?

    The CSockets have OnReceive functions, my understanding of them is that
    you implement them yourself and they then get called when any data is
    sitting
    on the Socket (i like this far better than an infinitely better idea than
    blocking
    my game's process .

    If this does get called from Windows, then it is not apart of my game's
    process, it runs parallel with it but does have access to all the functions.
    I
    haven't actually tested if this is true yet. If someone can verify that my
    understanding of how the OnReceive function works, that would be great.

    So it's like this
    // Multi-mine protocol CSocket
    MMPCSocket::OnReceive(int nErrorCode){
    Network::MMP msg; //enum for all the allowable protocol numbers.
    int bytes = Receive(&msg, sizeof(n->MMP));

    if(bytes == sizeof(n->MMP){ // read the correct number of bytes
    network->processPendingMessage(msg);
    }
    else{
    msg = network->mmp_server_received_bad_packet; //part of
    MMP
    Send(&msg, sizeof(n->MMP));
    network->deleteSocket(player);
    /* player is the reference to this socket */
    }
    }

    Network::deleteSocket(int player){
    delete myConnections[player];
    myConnections[player] = NULL;
    /* my current idea is that if a socket is null, means it can be reused
    for a new player */
    }

    Does that cause problems from the perspective of the game?
    I could imagine that there is a small possibility that just at this
    moment when I'm trying to delete it... my actual game is trying to send
    a message to it.

    Like within my game, it's going

    For(all my players)
    If(myConnections[player] != NULL){
    /* meanwhile, the deleteSocket has been run and
    it's gone and deleted the socket */
    int answer = myConnections[player].Send(some data, some
    number);
    }

    I don't see this as really being a problem.. because if the socket has
    been deleted, the Send message will return a WSANOTINITIALISED error to
    the GetLastError function. Whether I check or care about that is up to
    how I create my program, hopefully it wouldn't be necessary and the
    Network layer would have taken care of all that i.e. told all players
    that player x is gone now).

    The same goes if later on in the processPendingMessage part.. it finds
    out that the message is actually bogus.. it would also call the
    deleteSocket(player).

    Is this a smart way to go about things? An alternative to this would be just
    to
    Close the CSocket from within the OnReceive function.. then later on.. in my
    game process, every second or so.. check if any CSockets are closed, and
    delete them as required...

    Thanks for reading all the way to the end




  2. Re: My_CSockets::OnReceive(int nErrorCode){ delete this;} /* stupid or smart? */

    In a normal shutdown sequence, BSD sockets (winsock included) will attempt
    to finish sending your data prior to shutting down. Of course, there's
    always exceptions to the rule. See shutdown() for more info.

    Jeff www.bringitlive.com


    "Clive" wrote in message
    news:3f2174c5$0$23590$5a62ac22@freenews.iinet.net. au...
    > Hello everyone,
    >
    > This is my first time posting, up until now i've only used google to seach
    >
    >
    > I'm creating a multiplayer minesweeper game in Windows, so I have been
    > reading up on CSockets. I am begining to have a grasp on them, but I have
    > this one query.
    >
    > If a socket some data comes along that isnt part of my protocol, I want to
    > remove the close the socket and delete it. The main question is on a
    > OnReceive call can you tell the socket to delete itself?
    >
    > The CSockets have OnReceive functions, my understanding of them is that
    > you implement them yourself and they then get called when any data is
    > sitting
    > on the Socket (i like this far better than an infinitely better idea than
    > blocking
    > my game's process .
    >
    > If this does get called from Windows, then it is not apart of my game's
    > process, it runs parallel with it but does have access to all the

    functions.
    > I
    > haven't actually tested if this is true yet. If someone can verify that my
    > understanding of how the OnReceive function works, that would be great.
    >
    > So it's like this
    > // Multi-mine protocol CSocket
    > MMPCSocket::OnReceive(int nErrorCode){
    > Network::MMP msg; //enum for all the allowable protocol numbers.
    > int bytes = Receive(&msg, sizeof(n->MMP));
    >
    > if(bytes == sizeof(n->MMP){ // read the correct number of bytes
    > network->processPendingMessage(msg);
    > }
    > else{
    > msg = network->mmp_server_received_bad_packet; //part of
    > MMP
    > Send(&msg, sizeof(n->MMP));
    > network->deleteSocket(player);
    > /* player is the reference to this socket */
    > }
    > }
    >
    > Network::deleteSocket(int player){
    > delete myConnections[player];
    > myConnections[player] = NULL;
    > /* my current idea is that if a socket is null, means it can be reused
    > for a new player */
    > }
    >
    > Does that cause problems from the perspective of the game?
    > I could imagine that there is a small possibility that just at this
    > moment when I'm trying to delete it... my actual game is trying to send
    > a message to it.
    >
    > Like within my game, it's going
    >
    > For(all my players)
    > If(myConnections[player] != NULL){
    > /* meanwhile, the deleteSocket has been run and
    > it's gone and deleted the socket */
    > int answer = myConnections[player].Send(some data, some
    > number);
    > }
    >
    > I don't see this as really being a problem.. because if the socket has
    > been deleted, the Send message will return a WSANOTINITIALISED error to
    > the GetLastError function. Whether I check or care about that is up to
    > how I create my program, hopefully it wouldn't be necessary and the
    > Network layer would have taken care of all that i.e. told all players
    > that player x is gone now).
    >
    > The same goes if later on in the processPendingMessage part.. it finds
    > out that the message is actually bogus.. it would also call the
    > deleteSocket(player).
    >
    > Is this a smart way to go about things? An alternative to this would be

    just
    > to
    > Close the CSocket from within the OnReceive function.. then later on.. in

    my
    > game process, every second or so.. check if any CSockets are closed, and
    > delete them as required...
    >
    > Thanks for reading all the way to the end
    >
    >
    >




  3. Re: My_CSockets::OnReceive(int nErrorCode){ delete this;} /* stupid or smart? */

    Stay far, far away from the MFC's!

    --
    The designer of the experimental, SMP and HyperThread friendly, AppCore
    library.

    http://AppCore.home.comcast.net



  4. Re: My_CSockets::OnReceive(int nErrorCode){ delete this;} /* stupid orsmart? */

    Clive wrote:
    >
    > Hello everyone,
    >
    > This is my first time posting, up until now i've only used google to seach
    >
    >
    > I'm creating a multiplayer minesweeper game in Windows, so I have been
    > reading up on CSockets. I am begining to have a grasp on them, but I have
    > this one query.
    >
    > If a socket some data comes along that isnt part of my protocol, I want to
    > remove the close the socket and delete it. The main question is on a
    > OnReceive call can you tell the socket to delete itself?
    >
    > The CSockets have OnReceive functions, my understanding of them is that
    > you implement them yourself and they then get called when any data is
    > sitting
    > on the Socket (i like this far better than an infinitely better idea than
    > blocking
    > my game's process .
    >
    > If this does get called from Windows, then it is not apart of my game's
    > process, it runs parallel with it but does have access to all the functions.
    > I
    > haven't actually tested if this is true yet. If someone can verify that my
    > understanding of how the OnReceive function works, that would be great.
    >
    > So it's like this
    > // Multi-mine protocol CSocket
    > MMPCSocket::OnReceive(int nErrorCode){
    > Network::MMP msg; //enum for all the allowable protocol numbers.
    > int bytes = Receive(&msg, sizeof(n->MMP));
    >
    > if(bytes == sizeof(n->MMP){ // read the correct number of bytes
    > network->processPendingMessage(msg);
    > }
    > else{
    > msg = network->mmp_server_received_bad_packet; //part of
    > MMP
    > Send(&msg, sizeof(n->MMP));
    > network->deleteSocket(player);
    > /* player is the reference to this socket */
    > }
    > }
    >
    > Network::deleteSocket(int player){
    > delete myConnections[player];
    > myConnections[player] = NULL;
    > /* my current idea is that if a socket is null, means it can be reused
    > for a new player */
    > }


    You can delete the socket any time you want to, including inside
    OnReceive. The destructor calls Close for you if the socket is
    connected.

    CSocket is a blocking socket. If the network is slow it will block your
    game if you put it in the same thread as the game. You should use
    CAsyncSocket for nonblocking operation. With CAsyncSocket if the
    network is slow Send returns quickly with a "would block" error instead
    of blocking. This tells you to try again when OnSend comes in.

    Your OnReceive code is going to give you trouble. When you call receive
    it might give you only part of a message. That is normal. In that case
    you have to save what it gives you and wait for the next OnReceive. You
    never know how many bytes you're going to get: You have to put them back
    together into whole messages.

    --
    Scott McPhillips [VC++ MVP]

  5. Re: My_CSockets::OnReceive(int nErrorCode){ delete this;} /* stupid or smart? */


    "Scott McPhillips" wrote

    > CSocket is a blocking socket. If the network is slow it will block your
    > game if you put it in the same thread as the game. You should use
    > CAsyncSocket for nonblocking operation. With CAsyncSocket if the
    > network is slow Send returns quickly with a "would block" error instead
    > of blocking. This tells you to try again when OnSend comes in.


    So if I receive the "would block" error, I would have to add the current
    message to a queue to send along. A simple LinkList would be good for that.
    Does OnSend get called when the socket is empty and is available to send the
    next packet along? If this is true, I would then go ahead take the first
    message off the queue and send that along.

    I didn't really want to create multiple threads for all my connections.

    At the moment my game would only be played within my LAN network for
    testing, but these are definately concerns I should be addressing. Thankyou
    for pointing them out to me.

    >
    > Your OnReceive code is going to give you trouble. When you call receive
    > it might give you only part of a message. That is normal. In that case
    > you have to save what it gives you and wait for the next OnReceive. You
    > never know how many bytes you're going to get: You have to put them back
    > together into whole messages.


    Wow, thankyou for that information, it's certainly changed the way I am
    thinking of how to create my network layer in my head.

    The information I will be sending will always only ever be a number of
    bytes. I can't imagine I'll ever be sending a message over 20 bytes. From my
    understanding of IP networks is that each packet usually goes up to 1.5KB
    which is a lot more than the 20 that I would ever need. Never the less, are
    you still saying that it is possible that I may receive only one byte at a
    time? This is of a concern, because my protocol is an enum, which requires I
    get at least the first four bytes in one shot. Anything less and it would
    just mean more coding and more headaches

    I guess now that I know about this, I would just keep reading until I get
    the right number of bytes. Keep a buffer to put all packets into. GRR!
    Nothing is simple is it



  6. Re: My_CSockets::OnReceive(int nErrorCode){ delete this;} /* stupid orsmart? */

    Clive wrote:
    >
    > "Scott McPhillips" wrote
    >
    > > CSocket is a blocking socket. If the network is slow it will block your
    > > game if you put it in the same thread as the game. You should use
    > > CAsyncSocket for nonblocking operation. With CAsyncSocket if the
    > > network is slow Send returns quickly with a "would block" error instead
    > > of blocking. This tells you to try again when OnSend comes in.

    >
    > So if I receive the "would block" error, I would have to add the current
    > message to a queue to send along. A simple LinkList would be good for that.
    > Does OnSend get called when the socket is empty and is available to send the
    > next packet along? If this is true, I would then go ahead take the first
    > message off the queue and send that along.
    >
    > I didn't really want to create multiple threads for all my connections.
    >
    > At the moment my game would only be played within my LAN network for
    > testing, but these are definately concerns I should be addressing. Thankyou
    > for pointing them out to me.
    >
    > >
    > > Your OnReceive code is going to give you trouble. When you call receive
    > > it might give you only part of a message. That is normal. In that case
    > > you have to save what it gives you and wait for the next OnReceive. You
    > > never know how many bytes you're going to get: You have to put them back
    > > together into whole messages.

    >
    > Wow, thankyou for that information, it's certainly changed the way I am
    > thinking of how to create my network layer in my head.
    >
    > The information I will be sending will always only ever be a number of
    > bytes. I can't imagine I'll ever be sending a message over 20 bytes. From my
    > understanding of IP networks is that each packet usually goes up to 1.5KB
    > which is a lot more than the 20 that I would ever need. Never the less, are
    > you still saying that it is possible that I may receive only one byte at a
    > time? This is of a concern, because my protocol is an enum, which requires I
    > get at least the first four bytes in one shot. Anything less and it would
    > just mean more coding and more headaches
    >
    > I guess now that I know about this, I would just keep reading until I get
    > the right number of bytes. Keep a buffer to put all packets into. GRR!
    > Nothing is simple is it


    You are absolutely right that nothing is simple. Yes, OnSend gets
    called when the socket "unblocks". It probably means a reasonable
    amount of space is available, not necessarily that the socket is empty.
    By pausing when it blocks and resuming when it calls OnSend you are, in
    effect, handshaking with the network and the receiving machine. If the
    receiving machine gets real busy the result is that you wait for it.
    Note that on a LAN you will almost never get the "would block"
    condition. It happens when things slow down in the real world. You can
    simulate it by putting some delays in your client for test purposes.

    Yes, it is possible (unlikely) that you will receive only one byte at a
    time. And, it is possible that if two 20 byte messages are sent you
    will get 21 bytes, then 19 bytes. Winsock eliminates message
    boundaries. If you need the first four bytes as a packet length then
    save what you get, and only check for a whole packet when you have at
    least four bytes.

    OnReceive is an interesting function to write :-) I've got one that
    I've been using and reusing for several years, and to my surprise I had
    to make an improvement to it just last week. A new message handler
    (like your processPendingMessage) sometimes popped up a message box.
    That pumps Windows messages, which can cause reenty into OnReceive while
    it is already in a call to processPendingMessage. Very slippery stuff!

    --
    Scott McPhillips [VC++ MVP]

  7. Re: My_CSockets::OnReceive(int nErrorCode){ delete this;} /* stupid or smart? */

    You can't be sure how much bytes TCP/IP stack will send even sending 20
    bytes and as you correctly mention MTU of ethernet is 1500 bytes. The
    situation can be that
    TCP stack cannot take ( it's buffer is full ) all bytes but 19 only and send
    it and after that ( when ACK from peer host come back if Nagle algorithm
    switched on ( usually ) ) it will send additional last byte.
    Arkady


    "Clive" wrote in message
    news:3f22215c$0$23607$5a62ac22@freenews.iinet.net. au...
    >
    > "Scott McPhillips" wrote
    >
    > > CSocket is a blocking socket. If the network is slow it will block your
    > > game if you put it in the same thread as the game. You should use
    > > CAsyncSocket for nonblocking operation. With CAsyncSocket if the
    > > network is slow Send returns quickly with a "would block" error instead
    > > of blocking. This tells you to try again when OnSend comes in.

    >
    > So if I receive the "would block" error, I would have to add the current
    > message to a queue to send along. A simple LinkList would be good for

    that.
    > Does OnSend get called when the socket is empty and is available to send

    the
    > next packet along? If this is true, I would then go ahead take the first
    > message off the queue and send that along.
    >
    > I didn't really want to create multiple threads for all my connections.
    >
    > At the moment my game would only be played within my LAN network for
    > testing, but these are definately concerns I should be addressing.

    Thankyou
    > for pointing them out to me.
    >
    > >
    > > Your OnReceive code is going to give you trouble. When you call receive
    > > it might give you only part of a message. That is normal. In that case
    > > you have to save what it gives you and wait for the next OnReceive. You
    > > never know how many bytes you're going to get: You have to put them back
    > > together into whole messages.

    >
    > Wow, thankyou for that information, it's certainly changed the way I am
    > thinking of how to create my network layer in my head.
    >
    > The information I will be sending will always only ever be a number of
    > bytes. I can't imagine I'll ever be sending a message over 20 bytes. From

    my
    > understanding of IP networks is that each packet usually goes up to 1.5KB
    > which is a lot more than the 20 that I would ever need. Never the less,

    are
    > you still saying that it is possible that I may receive only one byte at a
    > time? This is of a concern, because my protocol is an enum, which requires

    I
    > get at least the first four bytes in one shot. Anything less and it would
    > just mean more coding and more headaches
    >
    > I guess now that I know about this, I would just keep reading until I get
    > the right number of bytes. Keep a buffer to put all packets into. GRR!
    > Nothing is simple is it
    >
    >




  8. Re: My_CSockets::OnReceive(int nErrorCode){ delete this;} /* stupid or smart? */

    Why ? That's thin shell around winsock which hide a lot of details , nice
    for lazy bones IMHO
    Arkady

    "SenderX" wrote in message
    news:eAkUa.146602$ye4.100810@sccrnsc01...
    > Stay far, far away from the MFC's!
    >
    > --
    > The designer of the experimental, SMP and HyperThread friendly, AppCore
    > library.
    >
    > http://AppCore.home.comcast.net
    >
    >




  9. Re: My_CSockets::OnReceive(int nErrorCode){ delete this;} /* stupid or smart? */

    You never said whether you were using stream (TCP) or datagram (UDP)
    sockets. CAsyncSocket::Receive() might return a partial message only
    if the socket was created as a stream socket. For a peer-to-peer (I
    assume) multi-player game, a datagram (UDP) socket might make more
    sense, because you wouldn't need a socket for each peer.

    With datagram sockets, Receive() will return only complete messages
    (if you provide large enough buffer :-). Of course, UDP is
    unreliable, so you would have to handle the possibility of dropped
    datagrams.

    To use a datagram socket in this scenario, you would bind the socket
    to INADDR_ANY plus your game port number, and ReceiveFrom() would
    return (whole) messages from any peer. If it mattered, you could
    determine which peer sent the message by looking at the sender's
    address.

    BTW, I don't use MFC socket classes myself, and lots of folks on this
    list recommend avoiding them.

    -- CCP

  10. Re: My_CSockets::OnReceive(int nErrorCode){ delete this;} /* stupidor smart? */



    Chris Pearson wrote:
    >
    > BTW, I don't use MFC socket classes myself, and lots of folks on this
    > list recommend avoiding them.
    >


    i see alot of people recommend this, and i could not agree more! i am
    relatively new to winsock, and so far i have had too many woes
    programming with mfc's CSocket and CAsyncSocket classes. so, i have 2
    questions open for anyone and everyone who has ever programmed with
    mfc's socket classes:

    1) why should we avoid using them?
    2) what should we use instead?


  11. Re: My_CSockets::OnReceive(int nErrorCode){ delete this;} /* stupid or smart? */


    "Jeremy Paiz" wrote in message
    news:84Xnb.7145$Px2.5234@newsread4.news.pas.earthl ink.net...

    > 1) why should we avoid using them?


    Because they provide no significant benefits, hide important details
    that you need to be able to access, and are not as well documented as the
    winsock functions they replace. There are *many* reasons.

    > 2) what should we use instead?


    Winsock2 directly. It gives you more control, more options, better
    performance, and is much better documented. It is perhaps slightly more
    difficult to get used to in the first place, but this is more than made up
    for by the reduction in long term pain.

    DS




  12. Re: My_CSockets::OnReceive(int nErrorCode){ delete this;} /* stupid or smart? */

    I've experienced some troubles with CSocket, and I think you must
    forget it if working in a multi-threaded environment. CSocket uses a
    "virtual window", hidden window that receives the socket messages. The
    problem is that when the socket in created within a thread, it will
    not be able to "see" any data if this data is not received while
    running the same thread. The CSocket objet will therefore never
    receive its message.

    But for simple projects, with no threads issues, I think its a simple
    way to do the job. If you're starting to create threads,
    and see you're not receiving the data you're supposed to, think of
    switching to the winsock API...

    "David Schwartz" wrote in message news:...
    > "Jeremy Paiz" wrote in message
    > news:84Xnb.7145$Px2.5234@newsread4.news.pas.earthl ink.net...
    >
    > > 1) why should we avoid using them?

    >
    > Because they provide no significant benefits, hide important details
    > that you need to be able to access, and are not as well documented as the
    > winsock functions they replace. There are *many* reasons.
    >
    > > 2) what should we use instead?

    >
    > Winsock2 directly. It gives you more control, more options, better
    > performance, and is much better documented. It is perhaps slightly more
    > difficult to get used to in the first place, but this is more than made up
    > for by the reduction in long term pain.
    >
    > DS


  13. Re: My_CSockets::OnReceive(int nErrorCode){ delete this;} /* stupid or smart? */

    CSocket is synchronous socket opposite to it's father ( base ) CAsyncSocket
    and maybe that caused problems for you especially in multithreading
    environment.
    OTOH any MFC socket class need be treated specially ( Detach() on thread
    which create it , create new socket class on the thread you want to use it
    and Attach() socket ( handle ) to that class ). You can see Q175668 of KB
    MSDN how to do that.
    http://support.microsoft.com/?kbid=175668
    Ruediger Asche in his article "Power Outlets in Action: Windows Sockets" in
    the MSDN wrote in
    "CSocket Objects and Multithreading" section :
    "This awareness of multithreading makes the CSocket object a little less
    generic than non-MFC sockets..."

    Arkady

    Arkady

    "Luis Menina" wrote in message
    news:d610bbcc.0310300559.167fd183@posting.google.c om...
    > I've experienced some troubles with CSocket, and I think you must
    > forget it if working in a multi-threaded environment. CSocket uses a
    > "virtual window", hidden window that receives the socket messages. The
    > problem is that when the socket in created within a thread, it will
    > not be able to "see" any data if this data is not received while
    > running the same thread. The CSocket objet will therefore never
    > receive its message.
    >
    > But for simple projects, with no threads issues, I think its a simple
    > way to do the job. If you're starting to create threads,
    > and see you're not receiving the data you're supposed to, think of
    > switching to the winsock API...
    >
    > "David Schwartz" wrote in message

    news:...
    > > "Jeremy Paiz" wrote in message
    > > news:84Xnb.7145$Px2.5234@newsread4.news.pas.earthl ink.net...
    > >
    > > > 1) why should we avoid using them?

    > >
    > > Because they provide no significant benefits, hide important details
    > > that you need to be able to access, and are not as well documented as

    the
    > > winsock functions they replace. There are *many* reasons.
    > >
    > > > 2) what should we use instead?

    > >
    > > Winsock2 directly. It gives you more control, more options, better
    > > performance, and is much better documented. It is perhaps slightly more
    > > difficult to get used to in the first place, but this is more than made

    up
    > > for by the reduction in long term pain.
    > >
    > > DS




  14. Re: My_CSockets::OnReceive(int nErrorCode){ delete this;} /* stupidor smart? */

    Jeremy Paiz wrote:
    >> BTW, I don't use MFC socket classes myself, and lots of folks on this
    >> list recommend avoiding them.
    >>

    >
    > i see alot of people recommend this, and i could not agree more! i am
    > relatively new to winsock, and so far i have had too many woes
    > programming with mfc's CSocket and CAsyncSocket classes. so, i have 2
    > questions open for anyone and everyone who has ever programmed with
    > mfc's socket classes:
    >
    > 1) why should we avoid using them?
    > 2) what should we use instead?
    >


    Several reasons to avoid CSocket are that it blocks windows message
    processing by your application, it lets you communicate in only one
    direction at a time, it has bugs that cause occasional lockups, and the
    winsock programmer's FAQ criticizes its adherence to winsock standards
    and good practices.

    OTOH, I find CAsyncSocket to be reliable and convenient and I have used
    it in many applications without problems. However, the knowledge that
    you need about socket programming is about the same for winsock and for
    CAsyncSocket. All CAsyncSocket does is make asynchronous socket
    notifications a little easier to integrate into a GUI app.

    --
    Scott McPhillips [VC++ MVP]


  15. Re: My_CSockets::OnReceive(int nErrorCode){ delete this;} /* stupid or smart? */

    Thanks for the information (and the link), Arkady...
    I think the CSocket help should have a warning about this, because
    blocking sockets are mostly used with threads. The one who doesn't
    want to use threads will use non-blocking sockets like CAsyncSocket...
    This is the kind of problem that make people switch to non-object
    solutions (winsock2)...

    "Arkady Frenkel" wrote in message news:...
    > CSocket is synchronous socket opposite to it's father ( base ) CAsyncSocket
    > and maybe that caused problems for you especially in multithreading
    > environment.
    > OTOH any MFC socket class need be treated specially ( Detach() on thread
    > which create it , create new socket class on the thread you want to use it
    > and Attach() socket ( handle ) to that class ). You can see Q175668 of KB
    > MSDN how to do that.
    > http://support.microsoft.com/?kbid=175668
    > Ruediger Asche in his article "Power Outlets in Action: Windows Sockets" in
    > the MSDN wrote in
    > "CSocket Objects and Multithreading" section :
    > "This awareness of multithreading makes the CSocket object a little less
    > generic than non-MFC sockets..."
    >
    > Arkady
    >
    > Arkady
    >
    > "Luis Menina" wrote in message
    > news:d610bbcc.0310300559.167fd183@posting.google.c om...
    > > I've experienced some troubles with CSocket, and I think you must
    > > forget it if working in a multi-threaded environment. CSocket uses a
    > > "virtual window", hidden window that receives the socket messages. The
    > > problem is that when the socket in created within a thread, it will
    > > not be able to "see" any data if this data is not received while
    > > running the same thread. The CSocket objet will therefore never
    > > receive its message.
    > >
    > > But for simple projects, with no threads issues, I think its a simple
    > > way to do the job. If you're starting to create threads,
    > > and see you're not receiving the data you're supposed to, think of
    > > switching to the winsock API...
    > >
    > > "David Schwartz" wrote in message

    > news:...
    > > > "Jeremy Paiz" wrote in message
    > > > news:84Xnb.7145$Px2.5234@newsread4.news.pas.earthl ink.net...
    > > >
    > > > > 1) why should we avoid using them?
    > > >
    > > > Because they provide no significant benefits, hide important details
    > > > that you need to be able to access, and are not as well documented as

    > the
    > > > winsock functions they replace. There are *many* reasons.
    > > >
    > > > > 2) what should we use instead?
    > > >
    > > > Winsock2 directly. It gives you more control, more options, better
    > > > performance, and is much better documented. It is perhaps slightly more
    > > > difficult to get used to in the first place, but this is more than made

    > up
    > > > for by the reduction in long term pain.
    > > >
    > > > DS


  16. Re: My_CSockets::OnReceive(int nErrorCode){ delete this;} /* stupid or smart? */

    You can find that in MSDN help , OTOH you can see that in the MFC code too
    ( used for learing and debug ).
    Arkady

    "Luis Menina" wrote in message
    news:d610bbcc.0310310024.1dd68f7c@posting.google.c om...
    > Thanks for the information (and the link), Arkady...
    > I think the CSocket help should have a warning about this, because
    > blocking sockets are mostly used with threads. The one who doesn't
    > want to use threads will use non-blocking sockets like CAsyncSocket...
    > This is the kind of problem that make people switch to non-object
    > solutions (winsock2)...
    >
    > "Arkady Frenkel" wrote in message

    news:...
    > > CSocket is synchronous socket opposite to it's father ( base )

    CAsyncSocket
    > > and maybe that caused problems for you especially in multithreading
    > > environment.
    > > OTOH any MFC socket class need be treated specially ( Detach() on thread
    > > which create it , create new socket class on the thread you want to use

    it
    > > and Attach() socket ( handle ) to that class ). You can see Q175668 of

    KB
    > > MSDN how to do that.
    > > http://support.microsoft.com/?kbid=175668
    > > Ruediger Asche in his article "Power Outlets in Action: Windows Sockets"

    in
    > > the MSDN wrote in
    > > "CSocket Objects and Multithreading" section :
    > > "This awareness of multithreading makes the CSocket object a little less
    > > generic than non-MFC sockets..."
    > >
    > > Arkady
    > >
    > > Arkady
    > >
    > > "Luis Menina" wrote in message
    > > news:d610bbcc.0310300559.167fd183@posting.google.c om...
    > > > I've experienced some troubles with CSocket, and I think you must
    > > > forget it if working in a multi-threaded environment. CSocket uses a
    > > > "virtual window", hidden window that receives the socket messages. The
    > > > problem is that when the socket in created within a thread, it will
    > > > not be able to "see" any data if this data is not received while
    > > > running the same thread. The CSocket objet will therefore never
    > > > receive its message.
    > > >
    > > > But for simple projects, with no threads issues, I think its a simple
    > > > way to do the job. If you're starting to create threads,
    > > > and see you're not receiving the data you're supposed to, think of
    > > > switching to the winsock API...
    > > >
    > > > "David Schwartz" wrote in message

    > > news:...
    > > > > "Jeremy Paiz" wrote in message
    > > > > news:84Xnb.7145$Px2.5234@newsread4.news.pas.earthl ink.net...
    > > > >
    > > > > > 1) why should we avoid using them?
    > > > >
    > > > > Because they provide no significant benefits, hide important

    details
    > > > > that you need to be able to access, and are not as well documented

    as
    > > the
    > > > > winsock functions they replace. There are *many* reasons.
    > > > >
    > > > > > 2) what should we use instead?
    > > > >
    > > > > Winsock2 directly. It gives you more control, more options,

    better
    > > > > performance, and is much better documented. It is perhaps slightly

    more
    > > > > difficult to get used to in the first place, but this is more than

    made
    > > up
    > > > > for by the reduction in long term pain.
    > > > >
    > > > > DS




  17. Re: My_CSockets::OnReceive(int nErrorCode){ delete this;} /* stupid or smart? */

    In article ,
    luis.menina@libertysurf.fr (Luis Menina) wrote:
    >I've experienced some troubles with CSocket, and I think you must
    >forget it if working in a multi-threaded environment.


    MFC is not exactly the most thread-safe of libraries to begin with.

    There are also a few wrinkles with MFC socket support - my favourite was
    that it would occasionally fail to read, and block the whole program.
    http://support.microsoft.com/?id=138694 - this suggests it's fixed, but the
    following suggests it's active at least in VS6.0:
    http://support.microsoft.com/?id=192704

    Alun.
    ~~~~

    [Please don't email posters, if a Usenet response is appropriate.]
    --
    Texas Imperial Software | Find us at http://www.wftpd.com or email
    1602 Harvest Moon Place | alun@texis.com.
    Cedar Park TX 78613-1419 | WFTPD, WFTPD Pro are Windows FTP servers.
    Fax/Voice +1(512)258-9858 | Try our NEW client software, WFTPD Explorer.

+ Reply to Thread