Develop Reference

c# Socket send receive network

I'm totally confused and stunned about my problem. I wrote a multi client server using sockets.
I created a first GUI that receives clients and display them in a gridview, in the click gridview event it opens a new GUI with the socket between the clicked client and the server. So everything about the connection between server and the clients go well and fast
But my problems are :
the send information between them like sending full process it sometimes shown full and it sometimes less result .
send files management for example when the server request full folders/files in a directory sometimes it shows them all and sometimes less result .
But the command such open a window open an url, send a message , commands like those works so perfectly and instantly .
I am so confused right now what's the problem
Notice 1 : I used the extern IP for connection between server/client.
Notice 2 : internet connection is perfect (definitely not slow)
I tried to use different buffer sizes, but what I'm really confused about is that sometimes the result comes full with a specific buffer size and sometimes not with the same buffer size .
Thank you for your time !

I would also recommend you use wireshark so that you are able to get the full information and transactions that are really going on in the network.
This will help you to rule out where the issue is coming from.
To determine the packet size see the image
Here I am not talking about how the TCP handshaking protocol works as I assume it is working. However do note that in the transmission if you see something like RST then maybe somebody issued a reset command implying that some error occurred in the transmission. Such as something due to checksum for example. Although it is generally a problem for someone working directly on TCP/IP protocol
This should help you confirm that you sent and recieved the correct length.

confused when receiving data from serial port

I encountered a problem that took me too much time, but without resolving it.soI really want you to help me.
I have an application built with c # wpf, and communicates with ovens via serial port.
the frame I need to send have following form: [EOT] (GID) (UID) (Temp) [ENQ]
gid uid: group identifier and unit identifier (address of the machine).
(eof),(enq) :frames the message.
(temp) means: give me the temperature value.
the only machine that has the same address can answer (master slave architecture).
the form of the response message is: [STX] (Temp) <DATA> [ETX].
the field contain only the temperature value
stx start text. etx end text.
I have no problem with sending and receiving of data, and I can display the value of temperature for a single machine connected.
but when I connect More machines, I do not know which machine has answered the frame that I sent, because the response frame does not have any adress so that I can determine which oven have respond.
So the situation in brief is:
-I send Data to ovens.
- I received data.
- I can not decide which oven answered.
please any one have an idea.
PS: I work with the protocol:EI-BISYNCH of eurotherm EuroTherm
If needed: EI-Bisynch ASCII Sequence Diagrams

In these conditions, the typical solution is:
Send the request to the current device
Wait for an answer for a defined timeout
If we receive an an answer within the timeout, the device responded.
If we do not receive an answer, the device is offline, mark it as such.
Switch to the next device, goto 1
Basically you should be able to wrap into a loop the code described here:
Providing Asynchronous Serial Port Communication
That is a sample that works with an AutoResetEvent. One of the .Net multithreading that allows synchronizing threads (the threads that sends the request in the loop, and the threads that receive the message in the loop)

IN these situations, the machine that you addressed is responding (or at least its assumed to be) Single Master - Multi Slaves. Meaning :-
Master -> Hey #1 tell me your temp -> #1 SIR! YES SIR! 23 degrees!
Master -> Hey #2...
The idea is no other slave will respond. By convention of the protocol.
Its pretty hard to do anything but this kind of system on serial.
In terms of Design if you create something like a command queue. Each command knows what device it wants to talk to, and what question it wants to ask. You process each command, send the serial message, get the response, and give it back to the command. Now you have a command, which knows which device it talked to, and what the response of that device was.

As long as you only have one "in-flight" command to which you are waiting for a response, and you know which device you sent the command to, you can assume that the device that responds next is the device you asked to respond. Now this won't necessarily always be true if it is possible for your device to send un-prompted responses.

How to safely stream data through a server socket to another socket?

I'm writing a server application for an iPhone application im designing. iPhone app is written in C# (MonoTouch) and the server is written in C# too (.NET 4.0)
I'm using asynchronous sockets for the network layer. The server allows two or more iPhones ("devices") to connect to each other and be able to send data bi-directionally.
Depending on the incoming message, the server either processes the message itself , or relays the data through to the other device(s) in the same group as the sending device. It can make this decision by decoding the header of the packet first, and deciding what type of packet it is.
This is done by framing the stream in a way that the first 8 bytes are two integers, the length of the header and the length of the payload (which can be much larger than the header).
The server reads (asynchronously) from the socket the first 8 bytes so it has the lengths of the two sections. It then reads again, up to the total length of the header section.
It then deserializes the header, and based on the information within, can see if the remaining data (payload) should be forwarded onto another device, or is something that the server itself needs to work with.
If it needs to be forwarded onto another device, then the next step is to read data coming into the socket in chunks of say, 1024 bytes, and write these directly using an async send via another socket that is connected to the recipient device.
This reduces the memory requirements of the server, as i'm not loading in the entire packet into a buffer, then re-sending it down the wire to the recipient.
However, because of the nature of async sockets, I am not guaranteed to receive the entire payload in one read, so have to keep reading until I receive all the bytes. In the case of relaying onto its final destination, this means that i'm calling BeginSend() for each chunk of bytes I receive from the sender, and forwarding that chunk onto the recipient, one chunk at a time.
The issue with this is that because I am using async sockets, this leaves the possibility of another thread doing a similar operation with the same recipient (and therefore same final destination socket), and so it is likely that the chunks coming from both threads will get mixed up and corrupt all the data going to that recipient.
For example: If the first thread sends a chunk, and is waiting for the next chunk from the sender (so it can relay it onwards), the second thread could send one of its chunks of data, and corrupt the first thread's (and the second thread's for that matter) data.
As I write this, i'm just wondering is it as simple as just locking the socket object?! Would this be the correct option, or could this cause other issues (e.g.: issues with receiving data through the locked socket that's being sent BACK from the remote device?)
Thanks in advance!

I was facing a similar scenario a while back, I don't have the complete solution anymore, but here's pretty much what I did :
I didn't use sync sockets, decided to explore the async sockets in C# - fun ride
I don't allow multiple threads to share a single resource unless I really have to
My "packets" were containing information about size, index and total packet count for a message
My packet's 1st byte was unique to signify that it's a start of a message, I used 0xAA
My packets's last 2 bytes were a result of a CRC-CCITT checksum (ushort)
The objects that did the receiving bit contained a buffer with all received bytes. From that buffer I was extracting "complete" messages once the size was ok, and the checksum matched
The only "locking" I needed to do was in the temp buffer so I could safely analyze it's contents between write/read operations
Hope that helps a bit

Not sure where the problem is. Since you mentioned servers, I assume TCP, yes?
A phone needs to communicate some of your PDU to another phone. It connects as a client to the server on the other phone. A socket-pair is established. It sends the data off to the server socket. The socket-pair is unique - no other streams that might be happening between the two phones should interrupt this, (will slow it up, of course).
I don't see how async/sync sockets, assuming implemented correctly, should affect this, either should work OK.
Is there something I cannot see here?
BTW, Maciek's plan to bolster up the protocol by adding an 'AA' start byte is an excellent idea - protocols depending on sending just a length as the first element always seem to screw up eventually and result in a node trying to dequeue more bytes that there are atoms in the universe.
Rgds,
Martin
OK, now I understand the problem, (I completely misunderstood the topology of the OP network - I thought each phone was running a TCP server as well as client/s, but there is just one server on PC/whatever a-la-chatrooms). I don't see why you could not lock the socket class with a mutex, so serializing the messages. You could queue the messages to the socket, but this has the memory implications that you are trying to avoid.
You could dedicate a connection to supplying only instructions to the phone, eg 'open another socket connection to me and return this GUID - a message will then be streamed on the socket'. This uses up a socket-pair just for control and halves the capacity of your server :(
Are you stuck with the protocol you have described, or can you break your messages up into chunks with some ID in each chunk? You could then multiplex the messages onto one socket pair.
Another alternative, that again would require chunking the messages, is introduce a 'control message', (maybee a chunk with 55 at start instead of AA), that contains a message ID, (GUID?), that the phone uses to establish a second socket connection to the server, passes up the ID and is then sent the second message on the new socket connection.
Another, (getting bored yet?), way of persuading the phone to recognise that a new message might be waiting would be to close the server socket that the phone is receiving a message over. The phone could then connect up again, tell the server that it only got xxxx bytes of message ID yyyy. The server could then reply with an instruction to open another socket for new message zzzz and then resume sending message yyyy. This might require some buffering on the server to ensure no data gets lost during the 'break'. You might want to implement this kind of 'restart streaming after break' functionality anyway since phones tend to go under bridges/tunnels just as the last KB of a 360MB video file is being streamed :( I know that TCP should take care of dropped packets, but if the phone wireless layer decides to close the socket for whatever reason...
None of these solutions is particularly satisfying. Interested to see whay other ideas crop up..
Rgds,
Martin

Thanks for the help everyone, i've realised the simpliest approach is to use synchronous send commands on the client, or at least a send command that must complete before the next item is sent. Im handling this with my own send queue on the client, rather than various parts of the app just calling send() when they need to send something.

Why I can't get all UDP packets?

My program use UdpClient to try to receive 27 responses from 27 hosts. The size of the response is 10KB. My broadband incoming bandwidth is 150KB/s.
The 27 responses are sent from the hosts almost at the same time and for every 10 secs.
However, I can only receive 8 - 17 responses each time. The number of responses that I can receive is quite dynamic but within the range.
Can anyone tell me why? why can't I receive all?
I understand UDP is not reliable. but I tried receiving 5 - 10 responses at the same time, it worked. I guess the network links are not so bad.
The code is very simple. ON the 27 hosts, I just use UdpClient to send 10KB to my machine.
On my machine, I have one UdpClient receive datagrams. Each time I get a data, I create a thread to handle it (basically handling it means just print out "I received 10KB", but it runs in a thread).
listener = new UDPListener(Port);
listener.Start();
while (true) {
try {
UDPContext context = listener.Accept();
ThreadPool.QueueUserWorkItem(new WaitCallback(HandleMessage), context);
} catch (Exception) { }
}
If I reduce the size of the response down to 3KB, the case gets much better that roughly 25 responses can be received.
Any more idea? UDP buffer problems???

As you said yourself, UDP is not reliable. So chances are packets are dropped somewhere.
Note that packet drop is caused just as much by overloaded switches/routers/network cards as by bad links. If someone sends you 27 10Kb responses "simultaneously". it might very well be that the buffers of your network card, or a nearby switch are full, and packets get dropped.
Until you have some code to show, there's probably not much else to say.

The 10kb packets are probably being fragmented. If even one of the fragments is dropped, the packet can't be reassembled. Depending on your network, the 3kb packets may not be fragmented, but in any case they would be fragmented less, increasing the chances that they make it through. You could run a PMTU discovery tool to find out the largest packet size the links support.

I think that UDP is not reliable at all, so i think this trouble is because you are getting a bottleneck (how tipically it is call) UDP sends everything but disordered and without check
so i think you must create kind of this protocol using UDP, i tell this cause i already made it
the key is trying to send all the packages with an ID. this way the receiver knows wich packages are missing and could ask for them to the transmitter, like TCP normally does

c# ascii protocol problem

i have a program that send ASCII commands to a device via a serial port. The program is a demo and doesn't do what i want.
I am just trying to get the device to respond in c# and I'm not getting anything back.
all the serial port settings are correct.
I am sending exactly the same message as the demo software.
//e.g message <STX>ABC<EOT>
byte[] msg = new byte[5];
msg[0] = 0x02;
msg[1] = 0x41;
msg[2] = 0x42;
msg[3] = 0x43;
msg[4] = 0x04;
comport.write(msg, 0,msg.length)
the device is a monitor. The code was only an example. there isn't a heartbeat just a response for a correct message sent or a error message. the settings are standard 9600-8-N-1. "paperclip between pins 2 and 3 (TX and RX)." yeah i know the cable works because its the same one used with the product software that works. and im getting back what i send. I have used a virtual com program and everything seems alright. "6 bytes but initializing only the first 5. " sorry typo.
the SerialPort.DtrEnable and RtsEnable properties to true. are on by default in c#. i have tried the hyper terminal and am not getting a response with that either. I have sent \r and \n with no luck.

This C# Tutorial on Serial Port Communication should be able to help. I'm not sure if there is an appropriatei intrinsic caste between Hex and Byte through assignment in C#. That may be the source of your problem.
Device Heartbeat
Does the device send a DC2 or DLE response (heartbeat)? If so, try opening a COM port in Hyperterminal using basic 9600-8-N-1 settings and see if you get anything. Is there any STX, SYN, ETX commands sent back when you try to send a command? I'm not sure on the command-set implementation for the hardware you are trying to communicate with.
Checking COM Port Operation
Have you checked if your COM port is working properly? You can create a loopback by inserting a paperclip between pins 2 and 3 (TX and RX). This will loopback your COM port and in Hyper terminal you can open that COM port and type. The characters will echo back.
You can also use a piece of software called com0com to create virtual COM ports to test what you are sending before you actually send it.
It provides pairs of virtual COM ports that are linked via a nullmodem connetion. You can then use your favorite terminal application or whatever you like to send data to one COM port and recieve from the other one
Without anymore specific information, we'll be grasping at straws.

You're allocating and sending 6 bytes but initializing only the first 5.
Also, according to what you write, you're doing everything correctly, exactly as the demo program. Right? Then I can see only one solution: The device is pulling your leg!
Seriously: If one program works and your doesn't, there MUST be some difference.

By far the most common mistake is forgetting to turn on the hardware handshake signals. The device won't send anything if it thinks the host is turned off. Make sure you set the SerialPort.DtrEnable and RtsEnable properties to true.
As mentioned before, fix the array size. Although it probably won't help, the STX character ensures that junk is thrown away.
Check if basic hardware is okay with the Windows Hyperterminal applet. You can send the message you are trying to transmit by typing Ctrl+B, ABC, Ctrl+D

As others have suggested, it is good idea to check what is being sent and received with some kind of terminal software. I have had success with "realterm"-- it has nice displays of ascii or binary/hex views.

Since you are working with ASCII, another issue might be that you are not sending the correct line-terminating character. Some devices expect \r and others \n. Make sure you are setting that correctly.

the device is a monitor. The code was only an example.
there isn't a heartbeat just a response for a correct message sent or a error message.
the settings are standard 9600-8-N-1.
"paperclip between pins 2 and 3 (TX and RX)." yeah i know the cable works because its the same one used with the product software that works. and im getting back what i send. I have used a virtual com program and everything seems alright.
"6 bytes but initializing only the first 5. " sorry typo.
the SerialPort.DtrEnable and RtsEnable properties to true. are on by default in c#.
i have tried the hyper terminal and am not getting a response with that either.
I have sent \r and \n with no luck.