I am new to fix. I am using quick fix library in my app. Im able to do logon and exchange heart beat. When i send the marketdata request, im getting the response from the server. But my application is sending reject message to fix, when it receives a message. And so im not able to process the message. Below are the incoming and outgoing message.
20160623-11:19:45.898 : 8=FIX.4.49=24235=X34=12049=CfhDemoPrices52=20160623-11:19:46.41456=PrimoDEMOFIX262=PrimoApp123268=2279=1269=0278=30/23-14404955=GBPUSD270=1.48854271=1500000290=164=20160627279=1269=1278=30/23-14405455=GBPUSD270=1.48885271=1000000290=110=004
20160623-11:19:45.924 : 8=FIX.4.49=13735=334=12249=PrimoDEMOFIX52=20160623-11:19:45.92256=CfhDemoPrices45=12058=Tag not defined for this message type371=55372=X373=210=140
and below is how i subscribe for market data:
QuickFix.FIX44.MarketDataRequest msg = new QuickFix.FIX44.MarketDataRequest();
// Fill message fields
msg.SetField(new MDReqID("PrimoApp123"));
msg.SetField(new SubscriptionRequestType('1'));
msg.SetField(new MarketDepth(1));
msg.SetField(new MDUpdateType(1));
// Add the MDEntryTypes group
QuickFix.FIX44.MarketDataRequest.NoMDEntryTypesGroup noMDEntryTypes = new QuickFix.FIX44.MarketDataRequest.NoMDEntryTypesGroup();
noMDEntryTypes.SetField(new MDEntryType('0'));
msg.AddGroup(noMDEntryTypes);
// Add the NoRelatedSym group
QuickFix.FIX44.MarketDataRequest.NoRelatedSymGroup noRelatedSym = new QuickFix.FIX44.MarketDataRequest.NoRelatedSymGroup();
noRelatedSym.SetField(new Symbol("GBPUSD"));
msg.AddGroup(noRelatedSym);
// Send message
Session.SendToTarget(msg, FeederApp.mysession);
Please help me with this if possible
Did you even look at what your reject message says?
45=120 // RefSeqNum - seq num of message that was rejected
58=Tag not defined for this message type
371=55 // RefTagID - tag 55 is the problem
372=X // RefMsgType - the rejected message was an X (MarketDataIncrementalRefresh)
373=2 // SessionRejectReason 2=[TagNotDefinedForThisMessageType]
So according to this, the problem is that your DataDictionary is not configured to expect tag 55 (Symbol) inside of message type X.
However, that doesn't appear to be entirely accurate. If you're pasted message is correct, it breaks down like this:
8 =FIX.4.4
9 =242
35 =X
34 =120
49 =CfhDemoPrices
52 =20160623-11:19:46.414
56 =PrimoDEMOFIX
262 =PrimoApp123
268 =2 // 2 MDEntry Sequences
279 =1 // 1st sequence
269 =0
278 =30/23-144049
55 =GBPUSD // this looks ok here...
270 =1.48854
271 =1500000
290 =1
64 =20160627 // what? this doesn't belong here!
279 =1 // 2nd sequence
269 =1
278 =30/23-144054
55 =GBPUSD
270 =1.48885
271 =1000000
290 =1
10=004
Therefore, I suspect that either (1) you made an error when you copy/pasted your message, or (2) it's actually field 64 that is your problem.
Next Steps:
1) Read this page to learn how to customize the DataDictionary:
http://quickfixn.org/tutorial/custom-fields-groups-and-messages.html
2) Get documentation from your counterparty and make sure your DataDictionary reflects all the field/message customizations that they have added to their system.
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)
I need to establish a connection from a public ip server implemented in c sharp to an android device behind the NAT and I was able to got SPD message from the android device using ICE4j library using this code
String toSend = SdpUtils.createSDPDescription(agent); //Each computer sends this information
and I got the following message
v=0
o=ice4j.org 0 0 IN IP4 192.168.1.14
s=-
t=0 0
a=ice-options:trickle
a=ice-ufrag:dikj41a5eequb2
a=ice-pwd:3t07qqjndu5pkneh53c6kqti3l
m=audio 5000 RTP/AVP 0
c=IN 192.168.1.14 IP4
a=mid:audio
a=candidate:1 1 udp 2130706431 fe80::1afe:34ff:fe29:c233 5000 typ host
a=candidate:2 1 udp 2130706431 192.168.1.14 5000 typ host
a=candidate:3 1 udp 1677724415 91.93.202.127 5000 typ srflx raddr 192.168.1.14 rport 5000
and the server stores this message so my question is what I have to do to establish a connection from the server to the android device using these information
In several Internet sources I've seen a general recommendation to disable sending Expect: 100-continue HTTP header in order to increase performance if the client is NOT actually going to send a large body.
However, testing the following code reveals that sending the header makes overall time decrease by ~50ms in average.
var hc = new HttpClient();
hc.DefaultRequestHeaders.ExpectContinue = ?;
hc.BaseAddress = new Uri("http://XXX/api/");
var r = new HttpRequestMessage(HttpMethod.Post, new Uri("YYY", UriKind.Relative))
{
Content = new StringContent("{}", Encoding.UTF8, #"application/json")
};
var tt = hc.SendAsync(r).Result;
tt.Content.ReadAsStringAsync().Result.Dump();
hc.Dispose();
Here is the WireShark dump for request with Expect: 100-continue
1 0.000000000 ss.ss.ss.176 dd.dd.dd.150 TCP 66 54515→80 [SYN] Seq=0 Win=8192 Len=0 MSS=1260 WS=4 SACK_PERM=1
2 0.342137000 dd.dd.dd.150 ss.ss.ss.176 TCP 66 80→54515 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1380 WS=1 SACK_PERM=1
3 0.342687000 ss.ss.ss.176 dd.dd.dd.150 TCP 54 54515→80 [ACK] Seq=1 Ack=1 Win=66780 Len=0
4 *REF* ss.ss.ss.176 dd.dd.dd.150 HTTP 272 POST /XXX/api/YYY HTTP/1.1
5 0.361158000 dd.dd.dd.150 ss.ss.ss.176 HTTP 79 HTTP/1.1 100 Continue
6 0.361846000 ss.ss.ss.176 dd.dd.dd.150 TCP 56 54515→80 [PSH, ACK] Seq=219 Ack=26 Win=66752 Len=2
7 0.705497000 dd.dd.dd.150 ss.ss.ss.176 HTTP 461 HTTP/1.1 200 OK (application/json)
8 0.726029000 ss.ss.ss.176 dd.dd.dd.150 TCP 54 54515→80 [FIN, ACK] Seq=221 Ack=433 Win=66348 Len=0
9 1.067923000 dd.dd.dd.150 ss.ss.ss.176 TCP 54 80→54515 [FIN, ACK] Seq=433 Ack=222 Win=65535 Len=0
10 1.068466000 ss.ss.ss.176 dd.dd.dd.150 TCP 54 54515→80 [ACK] Seq=222 Ack=434 Win=66348 Len=0
The same request without the header:
11 9.300455000 ss.ss.ss.176 dd.dd.dd.150 TCP 66 54516→80 [SYN] Seq=0 Win=8192 Len=0 MSS=1260 WS=4 SACK_PERM=1
12 9.640626000 dd.dd.dd.150 ss.ss.ss.176 TCP 66 80→54516 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1380 WS=1 SACK_PERM=1
13 9.641393000 ss.ss.ss.176 dd.dd.dd.150 TCP 54 54516→80 [ACK] Seq=1 Ack=1 Win=66780 Len=0
14 *REF* ss.ss.ss.176 dd.dd.dd.150 HTTP 250 POST /XXX/api/YYY HTTP/1.1
15 0.406794000 dd.dd.dd.150 ss.ss.ss.176 TCP 54 80→54516 [ACK] Seq=1 Ack=197 Win=65535 Len=0
16 0.406963000 ss.ss.ss.176 dd.dd.dd.150 TCP 56 54516→80 [PSH, ACK] Seq=197 Ack=1 Win=66780 Len=2
17 0.749589000 dd.dd.dd.150 ss.ss.ss.176 HTTP 461 HTTP/1.1 200 OK (application/json)
18 0.769053000 ss.ss.ss.176 dd.dd.dd.150 TCP 54 54516→80 [FIN, ACK] Seq=199 Ack=408 Win=66372 Len=0
19 1.109276000 dd.dd.dd.150 ss.ss.ss.176 TCP 54 80→54516 [FIN, ACK] Seq=408 Ack=200 Win=65535 Len=0
20 1.109742000 ss.ss.ss.176 dd.dd.dd.150 TCP 54 54516→80 [ACK] Seq=200 Ack=409 Win=66372 Len=0
Same results were received for IIS 7.5, IIS 8.0
The questions are:
What makes the request with the Expect header execute faster, when theoretically the opposite shall take place?
Is it always the case that the body of POST request goes within a separate TCP packet (I've looked through only a couple of samples, there this is true)? Here I mean why TCP packet at line 14 in dump does not contain the data (POST body) that was sent in TCP packet at line 16?
I had the same problem (~50 ms of delay). I guess it's a bug on HttpClient implementation of .NET Framework.
I made some test with .NET Core 2.1 and I was able to remove Continue message without performance decay.
Resolved same problem with TcpClient
var tcpClient = new TcpClient();
var uri = new Uri(httpAddress);
tcpClient.Connect(uri.Host, uri.Port);
string httpResponse = null;
using (NetworkStream networkStream = tcpClient.GetStream())
{
var httpRequestBuilder = new StringBuilder();
httpRequestBuilder.AppendLine("POST / HTTP/1.1");
httpRequestBuilder.Append("Host: ").AppendLine(uri.Host);
httpRequestBuilder.AppendLine("Content-Type: application/json");
httpRequestBuilder.Append("Content-Length: ").AppendLine(postJsonBody.Length.ToString());
httpRequestBuilder.AppendLine();
httpRequestBuilder.AppendLine(postJsonBody);
var httpRequest = httpRequestBuilder.ToString();
var requestBytes = Encoding.UTF8.GetBytes(httpRequest);
// sending request as one package
// (without PSH)
networkStream.Write(requestBytes, 0, requestBytes.Length);
// reading response
using (var sr = new StreamReader(networkStream, Encoding.UTF8))
{
httpResponse = sr.ReadToEnd();
}
}
tcpClient.Close();
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));