We found a weird problem in our test, when sending a http2 packets, even the total data is not very big, we found the single packet will be splitted into 2 or 3 packets, 1 with header and 1 or 2 packet with Json data. Could any know which setting could solve this problem to put them in one single packet when size allowed. Thanks a lot.
Related
I am Trying to run My IS08583 Script for Multiple Users using JPOS Plugin. However i could find below Output in the Sampler Result. Can anyone suggest what settings needs to be changed in JPOS for running my Script on Multiple users without this Error. Currently i am running only 2 Threads, in which one thread gives successful Output and Other gives error as mentioned below..
Thread Name: GBM_Transaction
Sample Start: 2020-08-24 15:45:13 IST
Load time: 1
Connect Time: 0
Latency: 0
Size in bytes: 0
Sent bytes:0
Headers size in bytes: 0
Body size in bytes: 0
Sample Count: 1
Error Count: 1
Data type ("text"|"bin"|""): text
Response code:
Response message: org.jpos.iso.ISOException: Duplicate key 'jmeter-2d8b3043-send.120000003938777.req' detected
SampleResult fields:
ContentType:
DataEncoding: null
When sending and receiving multiple request and response messages over the same socket connection,
jPOS needs to match responses (as they may come in in a different order) to requests.
It does that based on keys it generates for each message, e.g. jmeter-2d8b3043-send.120000003938777.req.
The part 120000003938777 is generated (by default) from the fields MTI (1200), DE41 and DE11 (00003 and 938777 presumably).
If your script does not vary those fields e.g. randomly, as suggested, the same key will be generated
for multiple messages and you get that error when jPOS detects the duplicate key.
Obviously, this makes it impossible to unambiguously match responses to requests.
What you can do is:
vary the fields DE41 and/or DE11, or
in case your messages do not contain those fields, define different keys in the "ISO8583 Connection Configuration" under "Mux Key Configuration" and vary those.
The JMeter functions ${__time()} and ${__RandomString()} are quite useful for that.
Refer also https://github.com/jpos/jPOS/blob/master/doc/src/asciidoc/ch08/qmux.adoc#mti-mapping-and-default-key.
Disclaimer: I am the author of the JMeter ISO8583 plugin.
I need to find out what is the average size of request in gRPC when Im sending a string to server and receiving a string from server?
I read somewhere it should be around 20 Bytes but what I see in Network Monitor app is that the request is above 500 Bytes. So is it the smallest possible size of a gRPC message size or what?
For a single rpc, gRPC needs to do a few things:
Establish HTTP/2
(Optional) Establish TLS
Exchange headers for the RPCs (size depends on schema)
Exchange actual RPC messages (size depends on schema)
Close connection
gRPC is meant to be used for many RPCs on a single connection so the smallest possible rpc message is really the bytes used for 4.
[Edit]
I checked and the minimum data exchanged for an rpc is over 500 bytes, in terms of raw IP packets.
I used the gRPC helloworld.proto, changed to send an int32.
Inspecting packets in Wireshark showed the following IP packet totals:
1286 bytes to establish connection, exchange headers and do the first rpc
564 bytes for each subsequent rpc
176 bytes for client Shutdown
Of those 546 "minimum" bytes:
67% was TCP/IP overhead (acknowledgements, packet headers)
10% was "trailer" data sent after the rpc
I am trying to capture completed handshake frames in an WPA2 EAPOL authentication. The source can be a pcap file or live capture. My idea is to
identify message type of EAPOL (message 1, 2, 3 & 4)
compare Key Nonce (should be similar for message 1&3 , 2&4)
verify source and destination for all 4 messages.
if these conditions satisfy for the 4 sets of EAPOL frame then it is a complete handshake. (check timestamps in case of duplicate frames)
But I have observed that in a complete handshake, many times the message# 4 carries a Nonce of zero value instead of Nonce of message# 2.
What other fields should be considered while determining a complete handshake then?
I have built an audio stream for mp3 files, and each time client hits the audio it receives something like this:
But what it does is just plays 1 minute sample instead of 120 minute
What am I doing wrong here?
Not 100% sure because you didn't provide code or an example stream to test, but your handling of HTTP range requests is broken.
In your example request, the client sends Range: bytes=0-, and your server responds with a 1MiB response:
Content-Length: 1048576 (aka. 1 MiB)
Content-Range: 0-1048575/...
This is wrong, the client did not request this! It did request bytes=0-, meaning all data from position 0 to the end of the entire stream (See the http 1.1 RFC), i.e. a response equal to one without any Range. (IIRC, Firefox still sends the Range: bytes=0- to detect if the Server handles ranges in the first place).
This, combined with the Content-Length, leads the client (Firefox) to think the whole resource is just 1MiB in size, instead of the real size. I'd imagine the first 1 MiB of your test stream comes out as 1:06 of audio.
PS: The Content-Duration header (aka. RFC 3803) is something browsers don't usually implement at all and just ignore.
Just an idea. Did you tried some of the http 3xx header like:
'308 Resume Incomplete' or '503 Service Temporarily Unavailable' plus 'retry-after:2' or '413 Request Entity Too Large' plus 'retry-after:2'
when using ZMQ transfer data, the transmitted port is fast and the data is huge, but the receive port processing is slow and the data is accumulated between the two processes. Does any one know how to solve this problem? Thanks.
Instead of sending all the data at once, send in chunks instead. Somethings like this...
Client requests file 'xyz' from server
Server responds with file size only, ex: 10Mb
Client sets chunk size accordingly, ex: 1024b
Client sends read requests to server for chunks of data:
client -> server: give me 0 to 1023 bytes for file 'xyz'
server -> client: 1st chunk
client -> server: give me 1024 to 2047 bytes for file 'xyz'
server -> client: 2nd chunk
...and so on.
For each response, client persists chunk to disk.
This approach allows the client to throttle the rate at which data is transmitted from the server. Also, in case of network failure, since each chunk is persisted, there's no need to read file from beginning; the client can start requesting more chunks from the point before the last response failed.
You mentioned nothing on language bindings, but this solution should be trivial to implement in just about any language.