Home/ Questions/Q 8315949
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-08T21:14:45+00:00

I’m adding file sharing capabilities to a basic .NET asynchronous socket server. The payload

  • 0

I’m adding file sharing capabilities to a basic .NET asynchronous socket server. The payload I’d like clients to send is just my headers+commandID+binaryFileData. This server needs to service requests from VB6 clients in addition to the .NET clients.

The party responsible for the VB6 clients worked out a convoluted way to transfer a file that I’m not particularly impressed by. It involves sending a small block of the file, at the end of which the server asks for the next block. This party claims that the VB6 Winsock control doesn’t work well if you try to do a send with a large (“large” means anything not small — 1MB is “large”). This sounds absurd to me.

I want clients to write a single large payload to the socket, and just do message reassembly/hashing at the server end. Are there actually problems with large writes in VB6 Winsock control, or is the other party making excuses?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The claim of VB6 having problems with large (for small values of large) payloads is absolutely true. Even more so, the resulting problems differ from installation to installation and by the phase of the moon. Sending more than a MB to a VB6 winsock control is asking for trouble. Been there, done that, just believe me.

    That said, we went down another route: A function would accept a payload of arbitraty size, chunk it up in Megabytes and enqueue it. The winsock control events (SendComplete IIRC) would be used to dequeue the next Megabyte.

    This is transparent to the consuming app (a singel call, indifferent of payload size), with the quirks worked around on the sending side – this works reliably without any sophisticated protocol, as the problems are completly inside the client.

    • 0