Member Avatar for kerp

Hi

During the last 6 months or so I've worked on and off on a couple of a classes to send data over network using winsock and asynchronous sockets on windows. Basically my system works like this.

The server will send packets on a connection until WSAGetLastError() returns WSAEWOULDBLOCK
the server then proceeds to queue the rest of the packets on the connection. When the connection gets an FD_WRITE message it continues to send data where it left off.

The problem I'm having is that sometimes the sending will stop because of WSAEWOULDBLOCK but no FD_WRITE message is sent afterwards. The test I'm using is kind of ridiculous, I'm sending 58800 packets in one burst but hey, it's not fun if you're not pushing the limits. When I'm testing I have both applications on the same computer I don't think it should make any difference but who knows.

I've heard people say that you shouldn't use asynchronous sockets for something serious because they're unreliable, but I've never found anything that specifies what's so bad about them and tbh this isn't something serious I just want to learn. But even if they are, they can't be this bad. If you want I can post some code but I'm not on that computer right now, I will be tomorrow.

I'm sorry for the poor English, I'm really tired.
Thanks
Kerp

  • 2 Contributors
  • 1 Reply
  • 507 Views
  • 1 Week Discussion Span
  • Latest Post Latest Post by gusmcn
Member Avatar for gusmcn

Does your receive side code keep Receiving until it gets a WSAEWOULDBLOCK?
TCP is a stream protocol and doesn't deal in packets. There is no requirement for the stream to be delivered in the same number of packets as that transmitted. FD_WRITE should be issued again once the receiver feels able to receive more data.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.