Socket automatically closes after recv

Started by
10 comments, last by XaserIII 12 years, 8 months ago
Hi!

I'm currently working on a little socket programm, everything worked fine so far, but now I'm facing a problem I can't find any solution to. Maybe you can help me.

The Problem is, that the socket ist automatically closed after the very first packet ist completely sent by the client and recieved by the server. The Packet is sent in one step but recieved in three step. OPCODE, Data size, Data.

Every recv call is successfull (with MSG_WAITALL) but the last one (the data one) returns 0 wich means connection gracefully closed (which I didn't do in my own code, it happens by some side effect).

Do you have any idea what the problem could be?

Xaser
Advertisement
I don't understand what you mean by;

1) "the data one" or

2) that "Every recv call is successfull" given that you also say that the socket gets closed after the first packet arrives.

Could you explain a little more?

Also, what's on the other end of this connection?
Well,

As I said the packet is sent as one "chunk" with one send call completely by my client application but then recieved by my server application in three steps, three recv calls to distinguish between packet types. First it recieves the opcode, then it recieves the size of the actual packet data which is going to income to find out when the next package starts and then the data arrives which has exactly the size which was sent before.

So the first two recv calls work, also the third one recvieves what it should to, so it can be called a successfull call, but as the socket is then automatically closed and recv actually returns 0 even though all bytes were recieved its somehow gone wrong. And I just don't see why the socket is beeing closed then, even though everything seemed to have worked fine.

Greetz,
Xaser
What does the client do after it sends the data?
What does WSAGetLastError() tell you?

What does the client do after it sends the data?


Quite interesting, as I said the client itself is not closing the connection, indeed it doesn't even seem to know that the socket has been closed as it proceedes normally untill the next send / recv call.


What does WSAGetLastError() tell you?


on both sides returns zero. Thats why I said the connection is closed gracefully.

Greetz
Xaser
"also the third one recvieves what it should to, so it can be called a successfull call, but as the socket is then automatically closed and recv actually returns 0 even though all bytes were recieved its somehow gone wrong."

If the recv returns zero, how do you know it's read the bytes it was supposed to? Because they're in the buffer?

"also the third one recvieves what it should to, so it can be called a successfull call, but as the socket is then automatically closed and recv actually returns 0 even though all bytes were recieved its somehow gone wrong."

If the recv returns zero, how do you know it's read the bytes it was supposed to? Because they're in the buffer?



yes exactly and they are identical to the sent ones. Also I guess if it wasn't successfull, the socket would not have been closed gracefully and WSAGetLastError would not have returned zero.

Xaser
OK, can you use telnet as a client? Because we know telnet won't close the connection unexpectedly -- so this will find out if the problem is with the server or the client part of the connection.
Well eventually I managed to fix the problem myself.
Basically it had to do with my "Ultra Dynamic Packet Handling" which hat one corrupt line which actually always led to the situation that the recv acutally expected to recv 0 bytes.

Well thanks anyway^^

Greetz
Xaser

This topic is closed to new replies.

Advertisement