2

Thanks for reading and answering in advance!

I wrote a simple C# program that connects via sockets with a third-party tool. Whenever I send a string longer than 1024 characters, the third-party software throws an error. Now I am trying to find out if this is a problem of my socket code or one of the other software (EnergyPlus).

It is only a few lines of code, and if anyone has suggestions, they would be highly appreciated!

using System.IO;
using System.Net;
using System.Net.Sockets;
...
private int port = 1410;
private TcpListener listener;
private Stream s;
private StreamReader sr;
private StreamWriter sw;
private Socket soc;
...

Here it really starts:

listener = new TcpListener(port);
listener.Start();
soc = listener.AcceptSocket();

// now, the other program connects

soc.SetSocketOption(SocketOptionLevel.Socket,
        SocketOptionName.ReceiveTimeout, 10000);

s = new NetworkStream(soc);

sr = new StreamReader(s);
sw = new StreamWriter(s);
sw.AutoFlush = true; // enable automatic flushing

sw.WriteLine("more or less than 1024 characters");

...

This is the code I use. Anything I forgot? Anything I should take care of? I am glad about any suggestions.

The error I get from E+ is the following:

ExternalInterface: Socket communication received error value " 1" at time = 0.00 hours.
ExternalInterface: Flag from server " 0".
StayOnTarget
  • 11,743
  • 10
  • 52
  • 81
Teetrinker
  • 850
  • 1
  • 15
  • 30
  • Would be helpfull to know the error, that is thrown. Doesn't look like it's your fault on first sight though. – Eugen Rieck Feb 11 '12 at 13:51
  • Does the protocol spec cover long strings? – Marc Gravell Feb 11 '12 at 13:52
  • @MarcGravell: Do you mean the protocol of the win sockets etc. or the one of EnergyPlus? The second does not have an accessible spec on the net. But they have a helpdesk I will get in touch with. But I want to be sure about my code first. – Teetrinker Feb 11 '12 at 14:01
  • @EugenRieck: Hello Eugen, I appended the error value in the original post. Does it help anything? – Teetrinker Feb 11 '12 at 14:06
  • sounds like a server buffer issue. (poorly written server...) but i think you have to get them to fix it as you can't guarantee that there buffer won't get >1024 characters at a time. – madmik3 Feb 11 '12 at 14:10
  • From the sound of the error message I suspect this to be an application-layer, not a socket-layer error: I suspect WHAT you send is the problem, not HOW MUCH you send. The size of the message just triggers it. Ofcourse I could be wrong, as this is just guesswork – Eugen Rieck Feb 11 '12 at 14:25

1 Answers1

1

Yu need to look at the specification defined by EnergyPlus; any socket communication needs rules. There are two obvious options here:

  1. you aren't following the rules (maybe it is limited length, or maybe you need to write special marker bytes for this scenario)
  2. their server code doesn't implement the specification correctly (biggest causes are: buffer issues, or: assuming a logical frame arrives in a single network packet)

Actually, I find it interesting that it is doing anything yet, as there is no obvious "frame" there; TCP is a stream, so you ususally need frames to divide logical messages. This usually means one of:

  • a length prefix, with or without other header data
  • a cr/lf/crlf terminator (or other terminator), usually for text-based protocols
  • closing the socket (the ultimate terminator)

You do none of those, so in any server I write, that would be an incomplete message until something else happens. It sounds text-based; I'd try adding a cr/lf/crlf

Marc Gravell
  • 1,026,079
  • 266
  • 2,566
  • 2,900
  • The string to be sent follows a specific format (which is documented) and it contains information about when it reaches its end. But I don't have any information about how extra-long strings are treated. / I guess my question is more about if it is basically okay to send a long string like that via TCP or if that already has to be done in a different way. – Teetrinker Feb 11 '12 at 15:42
  • 1
    @Teetrinker yes, there's no issue there. It may be split into packets, though. There *is* an upper limit on what you can pass down in a single chunk, but that is **much** bigger, and would error at your end. Sounds like their bug, from what you say. – Marc Gravell Feb 11 '12 at 15:45