Link to home
Start Free TrialLog in
Avatar of flashd
flashdFlag for United States of America

asked on

Delphi + Winsock.. Send() function

when using the winsock send() function it returns how much data was sent but how can I check if the data was successfully delivered?
Avatar of Alisher_N
Alisher_N

if you use TCP/IP it guarantees the delivery
UDP does not
You must use some kind of protocol. When you send data, your server must send a reply and when client receives a reply, your send was delivered.
Avatar of flashd

ASKER

Yes, I am using TCP and thats what I thought. I am acting as the client as the server already exists.
My problem is this sometimes the data received by the server is corrupted.

I've been looking at some delphi examples that send data via TCP and they use.


MySocket := Socket(PF_INET, SOCK_STREAM, IPPROTO_TCP);

OR

MySocket := Socket(PF_INET, SOCK_STREAM, IPPROTO_IP);

which is the correct one or does it matter?

ASKER CERTIFIED SOLUTION
Avatar of JMu
JMu

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
zero is IP ;-)

/*
 * Constants and structures defined by the internet system,
 * Per RFC 790, September 1981, taken from the BSD file netinet/in.h.
 */

/*
 * Protocols
 */
#define IPPROTO_IP              0               /* dummy for IP */
#define IPPROTO_ICMP            1               /* control message protocol */
#define IPPROTO_GGP             2               /* gateway^2 (deprecated) */
#define IPPROTO_TCP             6               /* tcp */
#define IPPROTO_PUP             12              /* pup */
#define IPPROTO_UDP             17              /* user datagram protocol */
#define IPPROTO_IDP             22              /* xns idp */
#define IPPROTO_ND              77              /* UNOFFICIAL net disk proto */

#define IPPROTO_RAW             255             /* raw IP packet */
#define IPPROTO_MAX             256

if you can not receive reliably, just make simple cut_to_blocks and crc_check_and_confirm_received_block stuff.....
"Sometimes the data received by the server is corrupted" is a giveaway for incorrect Recv code. Remember Recv can return 1 byte legally and you often receive in one call LESS than what was sent. For example the Send() sends 2048 bytes, but a call to Recv only gets 1024 bytes. A subsequent call gets the rest. This is caused by buffering (or the lack of it), transmission errors (big blocks get corrupted so smaller ones are sent), or by proxy servers splitting for better network traffic.
   The normal technique is either
   1) send in the first four bytes the message length. Good for multiple messages across a permanent connection,
   2) keep receiving until the socket is closed (-1 from Recv)