Well, I've done some TCP socket programming in the past but haven't used the CAsyncSocket class. What is interesting for me is that listen() returns EWOULDBLOCK for you. listen() should never return EWOULDBLOCK if you take a look at its documentation. listen() is always blocking but only for a very short time, it either returns failure or does its job (establises incoming connection request queue, the backlog) and returns with success.
So whats wrong with your code? Here is my guess: After starting the listen you unnecessarily issue some other request on your listen socket (for example an accept() call) and that results in a WSAEWOULDBLOCK message that is not still not the end of the world, but strange and you should check out the reason for this. About the WSAEADDRINUSE problem: If your listening starts as expected then it allocates and uses a port on your machine. When you connect the client side should issue a connect() call that results in the following events: your server side receives an event and as a result calls accept(). Both the server side accept() call and the client side connect() call returns a socket that has random ports assigned. HOWEVER: If your misterious CAsyncSocket class calls bind() before the connect() call, then it will fix the port of the returned socket by the connect() call and if that is the same as the port on which your server is listening then the socket can not be created on the client side! You should make sure that bind isn't called before connect() allowing the connect() call to assign a random port for the client side socket! bind() is usually used before connect when your firewall allows only specific ports for the software to communicate.
Another side note: WSAEADDRINUSE might return if you shut down your program during debugging. In this case some of your sockets might stay alive inside the network subsystem because of lingering. In this case sometimes you have to wait for minutes for that socket object to diminish from the network subsystem so as to release your ports.
I have continued work and am partway through the Client code. The client initialize seems to be OK, the client Connect() gets WSA code 10035, socket in use. I am beginning to think that is to be expected.
Thanks for your time
Edit, I keep messing with the formatting trying to get the code blocks to display correctly. Having some difficulties there. Preview looks good, but when I post it does not. I think I have it, disabled the checkbox to treat my content as plain text. But this darn edit box keeps jumping around in the text.
You say you have problems with connecting and you copy paste everything here except the client code and connect. First go and check whether you (or your CAsyncSocket class) issue a bind() call to the client socket before the connect call.
Well then, I think I was doing things out of order. My dialog has all the pieces broken out so I performed the following steps:
Server::Initialize, wsa = 0
Client::Initialize, wsa = 0
Server::Listen, wsa = 0
Client::Connect wsa = 10035
Client::OnConnect() is called
Server::OnAccept() is called
Client::OnSend() is called
As noted earlier, I have all those methods defined but with no body and a breakpoint in each. Is this normal behavior? If so,...
Does Client::OnConnect() need to do anything?
Same for Server::OnAccept and Client::OnSend?
I am getting close. Next Step?
Thanks for your time
Edit again: I have this code in the function C_Server::Class_Accept() that is called via a button in the dialog.
Now I that I see C_Server::OnAccept() called, that code should be moved into the OnAccept method and executed automatically after the client connects. Then I would NOT have a manually called Accept() method in the server class.
There are numerous versions of the basic copy function, too many now. some of the new versions are declared safer because they incorporate a limiting count value. However, all the ones I have tried and inadvertenly tested just crash the application. I find that rather rude.
Are there any versions of ...cpy...() and ...printf...() that limit the count of characters copied to the space found in the destination string. Without an ungracefull app crash?
Are there any versions of ...cpy...() and ...printf...() that limit the count of
characters copied to the space found in the destination string.
Without an ungracefull app crash?
Unfortunately, No. Strcpy and printf are two of the most common functions that hackers use to exploit programming errors to "hack" into a program. When using these functions you need to pay extra attention to the size of your memory buffers and the actions you are performing on them.
You may have better luck with the C++ Standard Library.
The std::string class will manage your memory buffers, copies and concatenations.
std::cout doesn't have the program crash issues that you are running into.
In that case I wish to go on record as saying that we need a new set of these functions. These functions should be named ...strcpy_l(...) and ...printf_l(...), with the "l" (lower case L) standing for Limited. Under the covers, the function will examine the destination, determine the length of the destination, and quietly refuse to move more characters than the destination string can hold.
These will do what you are asking. Read the descriptions though, strncpy will not NULL terminate your string if it can't write all of the data to the buffer. This would open yourself up to another set of possibilities to crash your program.
All of my software is powered by a single Watt.
Last Visit: 31-Dec-99 19:00 Last Update: 18-Dec-14 23:41