Use one Socket to send and recieve data

What makes more sense?

• use one socket to send and receive data to/from a embedded hardware device
• use one socket to send data and separate socket to read data

Communication is not very intensive but the important point is to receive data as fast as possible. Application works under Wi开发者_Go百科ndows XP and up.

---

Sockets were designed for two way communication, so most likely the developers of the embedded device didn't design their system to work off two sockets.

I have some experience working with embedded hardware and I've seen them work various ways:

Device connects to your application and starts streaming data via UDP
In this scenario I've seen up to three sockets in play. One TCP listening socket that accepts a connection from the embedded device. The embedded device then sends through some connection parameters, such as how quickly it's going to send you the data. The embedded device then starts streaming data via upd. Once you've received the data you send a message down a second upd socket to say "I got that one". The device then starts streaming the next bit of data (again via upd). This then continues ad infinitum. I've seen variations where the initial TCP connection is skipped and device just constantly stream data.

Request/Response
How many sockets you'll need here depends on who's making the initial connection, as that'll determine who needs the listening socket. Since you're making the initial connection, I'll use that. This is the more connection oriented scenario. Here you make a connection to the device and request some data, the device then sends you the response to that data. In this scenarioyou can only use one socket. As the device will respond to each request on the socket it was received.

So to answer you question "What makes more sense?", it completely depends on the design of your embedded device. If it's responding on the same socket as you're requesting, the answer is simple as only one socket is possible. Streaming devices via upd should give better performance with two sockets, but again only if your device supports it.

As for the second part of your question, "to receive data as fast as possible.", that's easy go asynchronous. Here are some excellent blogs on asynchronous socket programming:

• .NET Sockets - Two Way - Single Client (C# Source Code - Included)
• .NET Sockets in Two Directions with Multiple Client Support (C# Source Code Included)

If you're using a custom/third party protocol to communicate with the device you can't go wrong having a read through these either:

• How to Transfer Fixed Sized Data With Async Sockets
• Part 2: How to Transfer Variable Length Messages With Async Sockets

---

Im no expert but is there any downside to just using one socket?

It can already send and receive and my guess is that you end up getting more overhead if you have one socket for reading and one for sending...