|
|
Thanks Sandip,
I am a little losting the context you are talking about. Do you mean in order to implement a dual interface,
- we need an additional customized interface, which implements IDispatch?
- or we need implement both an additional customized interface (and the customized interface inherits from IUnknown) and also implement IDispatch?
- or both the above two ways are fine?
regards,
George
|
|
|
|
|
SandipG  wrote:
ROTFLMAO! This must be your first reply to George! 
led mike
|
|
|
|
|
Steve Echols wrote: Been so long since I've done it, I'm a bit fuzzy on the details.
Yep, that's it, and that pretty much is the detail. 
led mike
|
|
|
|
|
Thanks led mike,
As you are here. Let me just rate your reply and ask you a question.
To implement dual interface is easy, i.e. making the component implement a customized interface, and making the customized interface inherits IDispatch. So, I think since it is easy, every COM component should implement it and be a dual interface. Why implementing dual interface is not mandatory -- i.e. for some other reasons, developer will not implement dual interface?
regards,
George
|
|
|
|
|
I've been writing a TCP/IP client program: C++, Winsock, Win32, multithreaded. Anyway, after I send a message or two and a subsequent receive, I then get a 10053 from Winsock. Windows XP. I am completely updated with MS so it isn't an old system dll. I checked their knowledge base and there's nothing that I haven't done - there isn't much anyway. What really kills me is that other TCP/IP programs: web browsers, email clients, FTP clients, etc... are operating fine. Is there some sort of trick that I am missing?
To reiterate, it works perfectly for at least one 'send' and 'recv'. The client is communicating with Apache.
Any ideas? (What's left of my hair is falling out over this!)
I've also removed my anti-virus and turned off my firewall to see if that will clear it up - it didn't.
modified on Friday, September 12, 2008 5:03 AM
|
|
|
|
|
10053 WSAECONNABORTED
An established connection was aborted by the software in your host machine.
LitteWindow wrote: Any ideas?
Yes - you're doing something wrong.
What does your send and receive code look like?
Mark
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://codeproject.freetls.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
Here's me receive************************
void TWinsock::receiveDataFromServer(string& sDataBuffer )
{
int iResult = 0;
int bytesReceived = 0;
char buffer[ERRORBUFFERLEN];
char receiveBuffer[RECEIVEBUFFERLEN]; // Needed for the C to C++
// Clear out any junk out of the receive buffer .....
memset(receiveBuffer,NULL,RECEIVEBUFFERLEN);
// Make sure the data buffer is empty....
sDataBuffer = "";
// Receive data until the server closes the connection
do {
iResult = recv(ConnectSocket, receiveBuffer, RECEIVEBUFFERLEN, 0);
if( iResult > 0 ){
bytesReceived = iResult;
string temp(receiveBuffer);
sDataBuffer += temp;
#ifdef _DEBUG
// cout << "So far recv'd ....\r\n" << temp << endl;
#endif
}
else if ( iResult == 0 ){
// isConnected = false;
// throw EWinsockException (WSAGetLastError(), "Connection closed\n" );
}
else{
sprintf_s(buffer, "recv failed: %d\n", WSAGetLastError());
throw EWinsockException ( WSAGetLastError(), string(buffer) );
}
} while( iResult > 0 );
// Move it to the passed variable
sDataBuffer = receiveBuffer;
}
Here's the send***************************************************
void TWinsock::sendDataToServer(string sDataBuffer )
{
int iResult;
char buffer[ERRORBUFFERLEN];
if( isConnected )
{
// Send an initial buffer
iResult = send( ConnectSocket, sDataBuffer.c_str(), sDataBuffer.length(), 0 );
if (iResult == SOCKET_ERROR) {
sprintf_s(buffer, "send failed: %d\n", WSAGetLastError());
closesocket(ConnectSocket);
isConnected = false;
WSACleanup();
throw EWinsockException ( WSAGetLastError(), string(buffer) );
}
}
else{
throw EWinsockException ( string("Socket not connected.") );
}
}
|
|
|
|
|
You should start by properly handling the send() and recv()
return values.
A successful recv() may get you all the bytes you requested or
just one byte. You need to call recv() until you get the
number of bytes requested.
Same with send(). A single send() call may send anywhere from 0
to the number of bytes you want to send. You need to account for
that as well.
It's interesting that you send variable length data but receive
a constant number of bytes...how do you keep that in sync?
What happens if RECEIVEBUFFERLEN is > or < the number of bytes sent?
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
The send: It's just a string of not more than a 200 bytes - for this one. I have another one that will chunk up a file to send but I haven't tested that one.
The recv: I have a while loop that will keep pulling off data (while( iResult > 0 )) while the return code from recv is greater than 0.
That's not good enough for Winsock? It would be surprising since these methods are basically the MS examples. I just OOP'd them.
|
|
|
|
|
LitteWindow wrote: That's not good enough for Winsock?
Sure, but the code you showed isn't correct and doesn't implement any
working protocol. That's the only code I have to work with.
LitteWindow wrote: I have a while loop that will keep pulling off data (while( iResult > 0 )) while the return code from recv is greater than 0.
Are the sockets in blocking mode?
How do you recv the proper number of bytes?
Also, you should be able to debug it live pretty easily.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
| Are the sockets in blocking mode? I think so. Whatever the default mode of Winsock is. How do you recv the proper number of bytes? If I haven't answered this - I loop until the recv returns something less than or equal to 0. Sorry, I'm a bit tired and I forget what I answered before and for some reason this site is really slow for me right now. Also, you should be able to debug it live pretty easily. Yes. I'm in Visual C++ Express and when I debug, everything looks fine. I haven't seen anything really weird happening in the debug windows. So, I'm really confused. Oh, before I forget - even if you can't give me a solution, thanks for giving me some things to think about.
|
|
|
|
|
LitteWindow wrote: I loop until the recv returns something less than or equal to 0
Then recvs will only happen until there's no more data sent.
Then recv will block until there's more data.
If you run in the debugger, break execution and see where the
receive thread is sitting. In the call to recv()?
You're using HTTP protocol? If so...
Are you parsing the reply properly?
Are you relying on the receive loop to end when the
connection is closed by the server? If so are you using
the appropriate keep-alive header?
Too many questions?
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Sending this to server ....
POST /index.txt HTTP/1.1
Host: 192.168.1.105
Connection: Keep-Alive, TE
TE: trailers, deflate, gzip, compress
User-Agent: Gallery Remote 1.5
Accept-Encoding: text/*, text/html, text/html;level=1, */*
qewr
The returned message is ->
HTTP/1.1 200 OK
Date: Sat, 13 Sep 2008 13:13:26 GMT
Server: Apache/2.2.9 (Fedora)
Last-Modified: Thu, 28 Aug 2008 01:36:16 GMT
ETag: "595979-2d-4557b29b66400"
Accept-Ranges: bytes
Content-Length: 45
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/plain; charset=UTF-8
|
|
|
|
|
All that HTTP protocol stuff has to be parsed properly
to recv the expected number of bytes. Are you doing that?
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Right now at this level I'm just getting a stream of data and pulling it off of the socket as long as the recv returns greater than 0. As soon as I get a 0, I en the loop that makes the recv call. So, no, I'm not parsing the response from the Apache.
I'm a bit confused. I don't see how not parsing the response from Apache would give me the 10053 from Winsock.
|
|
|
|
|
LitteWindow wrote: I don't see how not parsing the response from Apache would give me the 10053 from Winsock.
It wouldn't necessarily, but I did want to rule out bad
communication code that can cause the server to close the
connection, which it is allowed to do.
Even though keep-alive is being used, if there's anything
the server doesn't recognize (anything that doesn't follow
the protocol) it's free to close the connection, in which case you
have to re-connect.
You may want to study the HTTP protocol[^] closely to see how
connections are handled and what your responsibilities on the
client end are (see section 8 ).
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
| It's funny that you mention that. Apache is closing the connection when it send it's response. I did a telnet server 80 and typed 'GET' and got the close connection message. So I reconnect after every recv. I don't quite like it but I guess I have to do it. Thanks again.
|
|
|
|
|
LitteWindow wrote: Apache is closing the connection when it send it's response
Interesting. The response you showed earlier seemed to me
to indicate a keep-alive connection.
I thought
Connection: close
would be a more correct response in HTTP/1.1
Is it an old Apache server? Or maybe persistent connections
is turned off?
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
You are correct. I have tried to set this up as a persistent connection but it seams that the web server or app server (Gallery2) is not cooperating. Mix in Winsock's error reporting - Why my second send returns the bytes sent and afterward the recv returns SOCKERROR with WSAGetLastError giving me the 10053, I have no idea why it can't tell me that the server closed the connection instead.
I'm using HTTP/1.1 Apache/2.2.9 on Fedora 9.
I got it (my app) to work by closing the connection and then reconnecting after each message (do a send and recv and then reset the connection). I really don't like doing it as a solution but it works and the reconnect happens fast.
I get 200s back from Apache when doing basic web page requests and when I call the main.php in gallery2, I'm getting valid responses when I format their requests properly. I'm still working on that.
|
|
|
|
|
LitteWindow wrote: I got it (my app) to work by closing the connection and then reconnecting after each message
That's standard HTTP/1.0 behavior - one request/response per connection.
It's pretty inefficient, but it works.
Assuming there's not a proxy between your client and the server
that's giving you HTTP/1.0 behavior, you may be able to configure
Apache with better keep-alive settings.
For example:
Apache: KeepAliveTimeout Directive[^]
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
I vaguely remember that about HTTP. I was shown the telnet server port 80 thing back in 1997. And as far as reading the document, hundreds of pages of specs...mmmmmmmm...I resorted to Wireshark and just duped the calls.
No proxy between the client and server - although, that's something I need to consider and the fact that the user will not have any control over the server.
Cheers!
|
|
|
|
|
LitteWindow wrote: The send: It's just a string of not more than a 200 bytes -
Forgot this one...
How does the receiving end know how many bytes were sent?
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
The interface function need return a bool value,
I'm not sure if true/false is compatible for another app (any kind).
system
modified on Thursday, September 11, 2008 9:19 PM
|
|
|
|
|
followait wrote: I'm not sure if true/false is compatible for another app (any kind).
Zero and non-zero surely are, though.
"Love people and use things, not love things and use people." - Unknown
"The brick walls are there for a reason...to stop the people who don't want it badly enough." - Randy Pausch
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
