replacement for winsock

[gtripathi]

Hi,

I'm not sure if this is the right forum to ask this question, and if its not please point me to the correct place. We're using Intel NIC and our application sends/receives moderate size (300-500 bytes) UDP packets at a very high rate. Using Winsock on XP, we find that Winscok sendto() function calls start blocking, or begin returning error 10035 if non-blocking sockets are used, once the packet rate goes above 3500 packets per second. Since the total bandwidth used is 10-15% of the LAN speed (100 mbps), we suspect the problem to be with Winsock. This was further verified by using the client and server applications on the same machine, so that no actual traffic goes on to the physical network, and we found the same problem occurring. The problem worsens if the packet rate is increased further. My question therefore is, does the Intel C++ compiler comes with a separate socket library or NIC API, or does it also uses winsock. And if it too uses winsock, then is there a separate product from Intel that can be used to replace the winsock library for our application.

Appreciate if someone can help us on this.

[aazue]

Hi (You are welcome here with your subject perfectly accorded)
Unfortunately ,is no at this side when you can improved or resolve that you wait .
You can largely improve speed with use new programing asynchronous in your source socket.
Difficult to help you more precise , I work essential Unix side
Type datagram with checksum informed or stream
depend also how you have your configuration hardware.
Exist some card Intel with several MAC with an binary utility for (BONDING)
If i remember.
You having cross machine cascading connection (fiber? Rx Tx -> Tx Rx) or you use switch or is over wwww (PPPO E(A)?
Very large domain for understand where exactly probably the nail that slow.....
Best regards

[aazue]

Hi
Accidentally i have find in search an other side
http://msdn.microsoft.com/en-us/library/ms740668%28VS.85%29.aspx

WSAEWOULDBLOCK
10035

Resource temporarily unavailable.

This error is returned from operations on nonblocking sockets that cannot be completed immediately,
for example recv when no data is queued to be read from the socket.
It is a nonfatal error, and the operation should be retried later.
It is normal for WSAEWOULDBLOCK to be reported as the result from calling connect on a nonblocking SOCK_STREAM socket,
since some time must elapse for the connection to be established.

Add an (while for retry (timeout)) if busy in your socket.

I have make test Intel card PCI 64 100/Mb internal (first to secondary same model card in same machine)
no error ? (without added flag retry for error) (2 test UDP and TCP (stream) socket)
Remark about probably difference ? :
(my two socket tested use added inflate and deflate with encoding 7 bit (for correct binary transfer).

Graphical utility show charge almost full.. 60/70%
Used Open watcom (32b) only they compiler under my hand this machine.
Control the service that you have ready default Xp that you can eventually disable....
Also show parameter card (duplex,full duplex and other ext ....)if an change can improve better.
Question ?
Kernel Xp(32) and lib your compiler have (SCTP) possiility ?
Kind regards.
(forget) i have use port 1500 for two test .

Added:
For SCTP XP
http://www.sctp.be/sctplib/index.htm