SSH.NET getting entire output from a shellstream - c#

Ive encountered quite a strange phenomenon; When using the client.RunCommand() function, i get the entire output from the switch, but when using my own implementation:
SshClient cl = new SshClient(ip, username, password);
cl.Connect();
shell = cl.createShellStream("Tail", 80, 24,800, 600, 1024);
StreamWriter wr = new StreamWriter(shell);
StreamReader rd = new StreamReader(shell);
wr.AutoFlush = true;
wr.WriteLine("show int status");
string rep = shell.Expect("Switch_Wan#", new TimeSpan(0,0,3));
MessageBox.Show(rep, "Output");
I only get partial output, and a prompt saying --More--
How can I get the entire output from the switch?
An example for the partial output:
show int status
Port Name Status Vlan Duplex Speed Type
Fa0/1 Team7 connected 97 a-full a-100 10/100BaseTX
Fa0/2 Team7 connected 97 a-full a-100 10/100BaseTX
Fa0/3 Team7 connected 97 a-full a-100 10/100BaseTX
Fa0/4 Team7 connected 97 a-full a-100 10/100BaseTX
Fa0/5 Team7 connected 97 a-full a-100 10/100BaseTX
Fa0/6 Team7 disabled 97 auto auto 10/100BaseTX
Fa0/7 Team7 connected 97 a-full a-100 10/100BaseTX
Fa0/8 Team7 connected 97 a-full a-100 10/100BaseTX
Fa0/9 Team11 connected 11 a-full a-100 10/100BaseTX
Fa0/10 Team11 connected 11 a-full a-100 10/100BaseTX
Fa0/11 Team4 connected 94 a-full a-100 10/100BaseTX
Fa0/12 Team4 connected 94 a-full a-100 10/100BaseTX
Fa0/13 Team4 connected 94 a-full a-100 10/100BaseTX
Fa0/14 Team4 connected 94 a-full a-100 10/100BaseTX
Fa0/15 Team4 disabled 94 auto auto 10/100BaseTX
Fa0/16 Team11 connected 11 a-full a-100 10/100BaseTX
Fa0/17 Team11 connected 11 a-full a-100 10/100BaseTX
Fa0/18 Team11 connected 11 a-full a-100 10/100BaseTX
Fa0/19 Team4 connected 94 a-full a-100 10/100BaseTX
Fa0/20 Team4 connected 94 a-full a-100 10/100BaseTX
Fa0/21 Team4 connected 94 a-full a-100 10/100BaseTX
Fa0/22 Team4 connected 94 a-full a-100 10/100BaseTX
--More--
Switch_Wan#
While using the client.RunCommand() function i get the entire 48 ports in the output.
Thanks in advanced, if anything is not clear, please say so.
ps. before anyone suggests, no, i cant use client.RunCommand(), i must use streams.
p.p.s if anyone could explain the values that go into cl.CreateShellStream("Trail", 80, 24,800, 600, 1024); i would be very very thankful as i dont really understand what those values go into


Here's a shot in the dark... try this:
shell = cl.createShellStream("Tail", 0, 0, 0, 0, 1024)
I'm still new to SSH.NET, but I think this essentially sets your shell window size to infinite and so less/more does not come into play.


Just run "term len 0" at the start of your session and you can avoid the --More-- prompts altogether


EDIT: Adam Shortland gave a better answer: term len 0
Found the solution, but forgot to come back and answer.
SNMP (2nd option) is still a valid solution and you can use it to get a lot mor information, but for this question, the correct answer is the one by Adam.
This looks similar to what I was working on recently.
While Simon's answer will give you more data, it won't help if return more data than the shell size (e.g. if you have a big switch with a lot of ports).
There are two ways I tried to solve this:
read the latest line and check for presence of --More--
Problem with this is that based on the software version of the switch, this format was different. So this broke my usage.
The 2nd and better option for me was using SNMP to get this information.
If you just want information from a switch, I'll definitely use SNMP rather than SSH. All this information is very easy to obtain if you have the correct OIDs.
You'll need to do a SNMP walk to get this information. The library I used is SNMPSharp.NET (http://www.snmpsharpnet.com/)
As for the values that go into CreateShellStream method, here is the method declaration from the docs:
public ShellStream CreateShellStream(string terminalName, uint columns, uint rows, uint width, uint height, int bufferSize)

Related

System.TimeoutException being Thrown when Attempting to Write to Holding Registers using NModbus

I'm attempting to write a Modbus master program in C# that writes values into the holding registers of a single slave device over a RTU serial connection.
void SerialTimerTick(object sender, EventArgs e) {
_sp.WriteLine(inputText.ToString());
slaveAddress = (byte)slaveAddressNumericUpDown.Value;
startAddress = (ushort)startAddressNumericUpDown.Value;
registerAddress = (ushort)registerNumericUpDown.Value;
targetRegisterValue = (ushort)targetValueNumericUpDown.Value;
modbusMaster.WriteSingleRegister(slaveAddress, registerAddress, targetRegisterValue);
SerialTimer.Enabled = false;
sendButton.Enabled = true;
}
The problem is that when I attempt to send the write request to the slave, I get the following error:
System.TimeoutException: The operation has timed out.
which happens after the program outputs these numbers to the debug console in SharpDevelop three times, indicating three attempts:
254
120
128
34
32
25
To fix it, I've tried using break points to diagnose the problem, and it appears that NModbus is expecting some kind of ACKNOWLEDGE response from the slave in order to confirm that the data was sent correctly, only no such response is given.
When I look at my slave's communications feed, I see that something is happening on the slave's end when both the master and slave applications are running and my computer is connected to itself using two USB to Serial adapters:
Port COM 3 opened.
Port I/O buffers configured.
Port configured 256000,8,N,1
Timeouts configured (100ms/500ms)
Modem status : [CTS_][DSR_RING_]
RX: 0D 0A 0A 06 00 01
RX: 00 01 19 CA
RX: 01 06 00 01 00 01
RX: 19 CA
RX: 01 06 00 01 00 01
Instead, what I expected is for the first attempt to succeed and for the 40001 register to change its value from zero to one. I've tried changing NModbus versions, I've tried messing with the timeout and attempt settings of the IModbusMasterobject and I've also tried removing the exception entirely, which seems to be the only way I've gotten the program to work correctly, however this isn't an acceptable solution in my case.
The only thing I haven't tried so far is changing the slave application I'm using, which is currently the free PLC Simulator, which is written in C++ and not C#. This might be part of the problem, but I'm not sure.
I've only been using Modbus for a few weeks, and am working with a rather old version of the NModbus library. Any help would be much appreciated.

I haven't used NModbus, but I have written my own Modbus "stack" in C++ and C# so this answer is based more on my experience with Modbus than on how NModbus works.
There should be a response from Modbus commands EXCEPT when broadcasted (slave address 0). It should be normal operation for Modbus code to send the request and wait for a response. If the response is not received in a some specified amount of time, I would expect a timeout error.
Looking at the modbus spec; the write single register function should have an identical request and response ADU (if successful). It sounds like you are trying to write slave address 1 register 1 with a value 1. In that case, both the request response ADUs should be "01 06 00 01 00 01 19 CA" ("19 CA" is the correct CRC for this PDU). I do see what could be data from a request or response, but there seems to be something interfering:
RX: 0D 0A (NOT SURE WHAT THIS DATA IS FROM)
RX: 0A 06 00 01 00 01 19 CA (LOOKS CLOSE, BUT ADDRESS IS WRONG)
RX: 01 06 00 01 00 01 19 CA (LOOKS CORRECT)
RX: 01 06 00 01 00 01 (LOOKS CORRECT, BUT INCOMPLETE)
Just to test, try a much slower baud rate (9600) and use even parity. Some USB to Serial converters have driver parameters that can be tweaked. Do you have termination enabled on both converters (first and last devices terminated)? Is there a way to configure the NModbus response timeout?

Windows Firewall Rule doesn't work - Firewall API - C#

i programmed a small chat program which is coded in C#. It uses WCF, to communicate with other users in the local network. Furthermore it uses the Firewall API dll in System32 to add 4 rules which allows all ports for incoming/outgoing TCP and UDP connections for this program. This rules are adding themselfe in the current network configuration(Public, Private). When the program Is closing, it deletes the 4 rules.
The problem is, that the firewall ignores this rules and drops the data which Is incomming. When i deactivate the firewall on both pcs(the two which are communicating) it works without problems.
The firewall has this 4 rules activated but i don't really get it why the firewall drops the incoming data...
Tested on 4 different Windows 10 machines.
After I think 1,5 hours the firewall rules worked on one machine which Is also confusing me...
This is the method with that i create this rules:
private void FWRule(NET_FW_RULE_DIRECTION_ direction,
NET_FW_ACTION_ fwaction, NET_FW_IP_PROTOCOL_ protocol, bool add)
{
try
{
INetFwRule firewallRule = (INetFwRule)Activator.CreateInstance(Type.GetTypeFromProgID("HNetCfg.FWRule"));
INetFwMgr fwMgr = (INetFwMgr)Activator.CreateInstance(Type.GetTypeFromProgID("HNetCfg.FWMgr"));
firewallRule.Action = fwaction;
firewallRule.Enabled = true;
firewallRule.InterfaceTypes = "All";
firewallRule.serviceName ="Chatty";
firewallRule.Grouping = "Chatty";
firewallRule.Profiles = (int)NET_FW_PROFILE_TYPE_.NET_FW_PROFILE_CURRENT;
firewallRule.ApplicationName = Assembly.GetExecutingAssembly().Location;
if (protocol == NET_FW_IP_PROTOCOL_.NET_FW_IP_PROTOCOL_TCP)
firewallRule.Name = Assembly.GetExecutingAssembly().GetName().Name + " Server Remote TCP";
else if (protocol == NET_FW_IP_PROTOCOL_.NET_FW_IP_PROTOCOL_UDP)
firewallRule.Name = Assembly.GetExecutingAssembly().GetName().Name + " Server Remote UDP";
firewallRule.Protocol = (int)protocol;
INetFwPolicy2 firewallPolicy = (INetFwPolicy2)Activator.CreateInstance
(Type.GetTypeFromProgID("HNetCfg.FwPolicy2"));
firewallRule.Direction = direction;
if (add == true)
{
firewallPolicy.Rules.Add(firewallRule);
}
else
{
firewallPolicy.Rules.Remove(firewallRule.Name);
}
}
catch (Exception ex) { MessageBox.Show(ex.Message, "ERROR"); }
}
The log from the firewall of the Server program shows that the firewall drops the incoming TCP data from the client(the server port for TCP is 2310, the client port for TCP is random/not known):
2016-10-19 10:37:56 DROP ICMP :: ff02::1 - - 80 - - - - 130 0 - RECEIVE
2016-10-19 10:38:54 DROP TCP fe80::91c:1ba7:abfc:5e5f fe80::1c96:dc05:3b26:1eaa 50248 2310 72 S 1175516710 0 8192 - - - RECEIVE
2016-10-19 10:38:57 DROP TCP fe80::91c:1ba7:abfc:5e5f fe80::1c96:dc05:3b26:1eaa 50248 2310 72 S 1175516710 0 8192 - - - RECEIVE
2016-10-19 10:39:03 DROP TCP fe80::91c:1ba7:abfc:5e5f fe80::1c96:dc05:3b26:1eaa 50248 2310 68 S 1175516710 0 8192 - - - RECEIVE
2016-10-19 10:40:02 DROP ICMP :: ff02::1 - - 80 - - - - 130 0 - RECEIVE
2016-10-19 10:41:02 DROP TCP fe80::91c:1ba7:abfc:5e5f fe80::1c96:dc05:3b26:1eaa 50252 2310 72 S 4091559822 0 8192 - - - RECEIVE
2016-10-19 10:41:05 DROP TCP fe80::91c:1ba7:abfc:5e5f fe80::1c96:dc05:3b26:1eaa 50252 2310 72 S 4091559822 0 8192 - - - RECEIVE
2016-10-19 10:41:11 DROP TCP fe80::91c:1ba7:abfc:5e5f fe80::1c96:dc05:3b26:1eaa 50252 2310 68 S 4091559822 0 8192 - - - RECEIVE
2016-10-19 10:41:23 DROP TCP 192.168.1.100 192.168.1.121 50253 2310 52 S 3013060805 0 8192 - - - RECEIVE
2016-10-19 10:41:26 DROP TCP 192.168.1.100 192.168.1.121 50253 2310 52 S 3013060805 0 8192 - - - RECEIVE
2016-10-19 10:41:30 DROP TCP fe80::91c:1ba7:abfc:5e5f fe80::1c96:dc05:3b26:1eaa 50261 2310 72 S 1985828196 0 8192 - - - RECEIVE
2016-10-19 10:41:33 DROP TCP fe80::91c:1ba7:abfc:5e5f fe80::1c96:dc05:3b26:1eaa 50261 2310 72 S 1985828196 0 8192 - - - RECEIVE
2016-10-19 10:41:39 DROP TCP fe80::91c:1ba7:abfc:5e5f fe80::1c96:dc05:3b26:1eaa 50261 2310 68 S 1985828196 0 8192 - - - RECEIVE
2016-10-19 10:42:07 DROP ICMP :: ff02::1 - - 80 - - - - 130 0 - RECEIVE
2016-10-19 10:44:13 DROP ICMP :: ff02::1 - - 80 - - - - 130 0 - RECEIVE
2016-10-19 10:44:28 DROP TCP fe80::91c:1ba7:abfc:5e5f fe80::1c96:dc05:3b26:1eaa 50285 2310 72 S 2762432965 0 8192 - - - RECEIVE
2016-10-19 10:44:29 DROP TCP fe80::91c:1ba7:abfc:5e5f fe80::1c96:dc05:3b26:1eaa 50285 2310 72 S 2762432965 0 8192 - - - RECEIVE
2016-10-19 10:44:35 DROP TCP fe80::91c:1ba7:abfc:5e5f fe80::1c96:dc05:3b26:1eaa 50285 2310 68 S 2762432965 0 8192 - - - RECEIVE
The rule is registered in the Windows Firewall(sorry OS is in German):

Unrecognized Ciphers from mobile application

I'm writing an Android application with Xamarin (C#) that makes calls to Exchange Web Services. The code sets the out of office message. The code I have written works from a standard Windows Forms application, but fails with a "Request Invalid" SOAP exception. I've captured the requests using Fiddler, and it appears to be a cipher issue.
The Windows Forms request is this:
A SSLv3-compatible ClientHello handshake was found. Fiddler extracted the parameters below.
Version: 3.1 (TLS/1.0)
Random: 53 B1 31 EF DD 96 01 7E 0A 0A 1F 85 60 8F 2F BD D6 77 08 2D B0 C6 52 91 BC A0 19 2F 20 08 F1
SessionID: empty
Extensions:
renegotiation_info 00
server_name
elliptic_curves secp256r1 [0x17], secp384r1 [0x18]
ec_point_formats uncompressed [0x0]
Ciphers:
[002F] TLS_RSA_AES_128_SHA
[0035] TLS_RSA_AES_256_SHA
[0005] SSL_RSA_WITH_RC4_128_SHA
[000A] SSL_RSA_WITH_3DES_EDE_SHA
[C013] TLS1_CK_ECDHE_RSA_WITH_AES_128_CBC_SHA
[C014] TLS1_CK_ECDHE_RSA_WITH_AES_256_CBC_SHA
[C009] TLS1_CK_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
[C00A] TLS1_CK_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
[0032] TLS_DHE_DSS_WITH_AES_128_SHA
[0038] TLS_DHE_DSS_WITH_AES_256_SHA
[0013] SSL_DHE_DSS_WITH_3DES_EDE_SHA
[0004] SSL_RSA_WITH_RC4_128_MD5
Compression:
[00] NO_COMPRESSION
The Android request is this:
A SSLv3-compatible ClientHello handshake was found. Fiddler extracted the parameters below.
Version: 3.1 (TLS/1.0)
Random: 53 B1 30 9C 9A A2 AE 57 A9 98 A3 C8 DF 94 E0 04 1D 3F E1 34 A8 8A DF 8B 5E 8B 60 67 96 6D 1B
SessionID: empty
Extensions:
server_name
Ciphers:
[0035] TLS_RSA_AES_256_SHA
[002F] TLS_RSA_AES_128_SHA
[000A] SSL_RSA_WITH_3DES_EDE_SHA
[0005] SSL_RSA_WITH_RC4_128_SHA
[0004] SSL_RSA_WITH_RC4_128_MD5
[0009] SSL_RSA_WITH_DES_SHA
[0003] SSL_RSA_EXPORT_WITH_RC4_40_MD5
[0006] SSL_RSA_EXPORT_WITH_RC2_40_MD5
[0008] SSL_RSA_EXPORT_WITH_DES40_SHA
[0060] Unrecognized cipher - See http://www.iana.org/assignments/tls-parameters/
[0061] Unrecognized cipher - See http://www.iana.org/assignments/tls-parameters/
[0062] TLS_RSA_EXPORT1024_WITH_DES_SHA
[0064] TLS_RSA_EXPORT1024_WITH_RC4_56_SHA
Compression:
[00] NO_COMPRESSION
The "unrecognized cipher" message leaps out here. Any help on how to resolve this issue would be great.
thanks

That two ciphers are not recognized does not mean that there are no ciphers to choose from. Unless the TLS is explicitly broken down further on, it's likely another issue.
I think you are better off looking at the SOAP messages.

Why can't I send this IP packet?

I'm trying to send an IP packet using c#.
destAddress = IPAddress.Parse("192.168.0.198"),
destPort = 80;
// Create a raw socket to send this packet
rawSocket = new Socket(AddressFamily.InterNetwork, SocketType.Raw, ProtocolType.IP);
// Bind the socket to the interface specified
IPEndPoint iep = new IPEndPoint(IPAddress.Parse("192.168.0.140"),0);
rawSocket.Bind(iep);
// Set the HeaderIncluded option since we include the IP header
rawSocket.SetSocketOption( socketLevel, SocketOptionName.HeaderIncluded, 1 );
// Send the packet!
int rc = rawSocket.SendTo(builtPacket, new IPEndPoint(destAddress, destPort));
Console.WriteLine("sent {0} bytes to {1}", rc, destAddress.ToString());
The content of builtPacket is shown below. It's an IP packet containing a TCP SYN packet (That's what I think I created anyway).
45 00 00 28 00 00 00 00 02 06 36 6E C0 A8 00 8C
C0 A8 00 C6 14 1E 00 50 00 00 00 00 00 00 00 00
05 02 FF FF E6 4F 00 00
The output is:
sent 40 bytes to 192.168.0.198
The problem is I don't see anything in the Wireshark trace. It's like the data is not getting far enough down the stack for Wireshark to see it? If I use a browser to connect to 192.168.0.198, Wireshark shows all the packets, but shows nothing when I try to send a packet using the above code and data.
My config:
I am running as admin so it's not a permissions problem.
Windows7 ( Not running in a VM)
Wireless connection only (IP config reports its IP as 192.168.0.140)
What am I doing wrong?
I'm sure Occam's Razor applies here, but I've been looking at this for hours and can't figure out what's wrong.

This question, backed up by MSDN, claims that Windows no longer (XP SP 2 through 7) allows transmission of TCP data using raw sockets.

My guess is that either Wireshark is not looking at the right network interface, or that the destination ip address somehow resolves to the local machine, in which case it will routed inside of the OS and be invisible to the 'Shark.

TCP Socket Sending Delays and Retransmission

I have a .NET 3.5 C# application that sends 2000-6000 byte packets to a linux machine running sles 10. The machines are on the same subnet.
About 90% of the time, everything works fine. The linux machine processes my request and responds in 5-15ms. But about 10% of the time, there is an approx 200ms-800ms delay.
Looking at the logs on the linux machine, it seems the delay is on my end. That is, if my call to socket.Send(...) returns at 1:15:00.000 and I get a response at 1:15:00.210, the log on the linux machine says that it received the request at 1:15:00.200 and then processed it in 10ms. (I'm using System.Diagnostics.Stopwatch for timing on my machine.)
To debug, I captured the traffic using wireshark. Here is the traffic. Between No. 8 and 9 is where a 600 ms delay occurs. (137.34.210.108 is my machine and 137.34.210.95 is the linux machine).
"1","11:56:27.380318","137.34.210.95","137.34.210.108","TCP","20700 > 17479 [PSH, ACK] Seq=1 Ack=1 Win=32767 Len=76"
"2","11:56:27.380393","HewlettP_29:37:0f","Broadcast","ARP","Who has 137.34.210.95? Tell 137.34.210.108"
"3","11:56:27.380558","HewlettP_29:39:93","HewlettP_29:37:0f","ARP","137.34.210.95 is at 00:1b:78:29:39:93"
"4","11:56:27.380564","137.34.210.108","137.34.210.95","TCP","17479 > 20700 [ACK] Seq=1 Ack=77 Win=65459 [TCP CHECKSUM INCORRECT] Len=0"
"5","12:04:48.096892","HewlettP_29:37:0f","Broadcast","ARP","Who has 137.34.210.95? Tell 137.34.210.108"
"6","12:04:48.097216","HewlettP_29:39:93","HewlettP_29:37:0f","ARP","137.34.210.95 is at 00:1b:78:29:39:93"
"7","12:04:48.097229","137.34.210.108","137.34.210.95","TCP","17480 > 20600 [PSH, ACK] Seq=1 Ack=1 Win=64198 [TCP CHECKSUM INCORRECT] Len=458"
"8","12:04:48.097457","137.34.210.95","137.34.210.108","TCP","20600 > 17480 [ACK] Seq=1 Ack=4294964377 Win=32767 Len=0 SLE=1 SRE=459"
"9","12:04:49.700966","137.34.210.108","137.34.210.95","TCP","17479 > 20700 [ACK] Seq=1 Ack=77 Win=65459 [TCP CHECKSUM INCORRECT] Len=1460"
"10","12:04:49.701190","137.34.210.108","137.34.210.95","TCP","[TCP Retransmission] 17480 > 20600 [ACK] Seq=4294964377 Ack=1 Win=64198 [TCP CHECKSUM INCORRECT] Len=1460"
"11","12:04:49.703970","137.34.210.95","137.34.210.108","TCP","20600 > 17480 [ACK] Seq=1 Ack=4294965837 Win=32767 Len=0 SLE=1 SRE=459"
"12","12:04:49.703993","137.34.210.108","137.34.210.95","TCP","[TCP Retransmission] 17480 > 20600 [ACK] Seq=4294965837 Ack=1 Win=64198 [TCP CHECKSUM INCORRECT] Len=1460"
"13","12:04:49.704002","137.34.210.108","137.34.210.95","TCP","[TCP Retransmission] 17480 > 20600 [PSH, ACK] Seq=1 Ack=1 Win=64198 [TCP CHECKSUM INCORRECT] Len=458"
"14","12:04:49.704211","137.34.210.95","137.34.210.108","TCP","20600 > 17480 [ACK] Seq=1 Ack=459 Win=32767 Len=0"
"15","12:04:49.704215","137.34.210.95","137.34.210.108","TCP","[TCP Dup ACK 14#1] 20600 > 17480 [ACK] Seq=1 Ack=459 Win=32767 Len=0 SLE=1 SRE=459"
"16","12:04:49.705425","137.34.210.95","137.34.210.108","TCP","20700 > 17479 [PSH, ACK] Seq=77 Ack=1461 Win=32767 Len=44"
Can someone help me to interpret this? I see that a re-transmit is occurring. But I'm not sure why. The switch shows no dropped packets. And even if the packets are being lost, why would it take 600ms to re-transmit?
I thought that this (http://support.microsoft.com/kb/328890) might have something to do with the 200ms delays but I've tried changing the TcpAckFrequency and it didn't help.
Thanks,
Mike

Let's start by pruning some of that Wireshark output. We can toss the ARPs in packets 2, 3, 5 and 6. Looking at the rest, you have two sets of traffic in there. Packets 8 and 9 are two different connections, so you can't compare them. 7, 8 and 10, however, are part of one connection so let's examine those.
Packet 7 is 458 bytes of data being sent to the Linux box with a TCP sequence number of 1. However, the ACK that the Linux box returns is 4294964377. This means that Wireshark is showing relative TCP values and that the Linux box is not sending an ACK for packet 7, but for an earlier packet. Your PC then waits for a follow-up ACK and, when it doesn't get one, retransmits the required data. In this case the 458 bytes from packet 7 along with a previous 1002 bytes. That's why the sequence number from packet 10 matches the ACK from packet 8.
Unfortunately this doesn't tell you why data is being dropped. Packet 8 shows the Linux box indicating it still has a full 32k of input buffer available for this connection ("Win=32767").

This only shows the TCP packets on the Linux machine, but I'd recommend to look at the ip stats with the 'netstat -s' command. One reason for the retransmissions might be socket buffer overflows, which will be shown with this command.

I don't recall if Windows has it, but on UNIX you'd enable TCP_NODELAY.
This disables TCP's Nagle Algorithm which makes the system wait for a small time in case more data is going to be added to the transmit buffer.
int nodelay = 1;
setsockopt(s, IPPROTO_TCP, TCP_NODELAY, &nodelay, sizeof(nodelay));

Categories