When I try to send big text(about 40M) by using jetty websocket client, I got this ProtocolException:
org.eclipse.jetty.websocket.api.ProtocolException: Invalid control frame payload length, [142] cannot exceed [125]
at org.eclipse.jetty.websocket.common.Parser.assertSanePayloadLength(Parser.java:122)
at org.eclipse.jetty.websocket.common.Parser.parseFrame(Parser.java:482)
at org.eclipse.jetty.websocket.common.Parser.parse(Parser.java:254)
at org.eclipse.jetty.websocket.common.io.AbstractWebSocketConnection.readParse(AbstractWebSocketConnection.java:628)
at org.eclipse.jetty.websocket.common.io.AbstractWebSocketConnection.onFillable(AbstractWebSocketConnection.java:476)
at org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
at java.lang.Thread.run(Thread.java:745)
I modified the maxTextMessageSize to make it to send big text. Any ideas why the ws is closed?
org.eclipse.jetty.websocket.api.ProtocolException: Invalid control frame payload length, [142] cannot exceed [125]
That says the websocket implementation received a WebSocket Control Frame (CLOSE, PING, PONG) that had 142 bytes of payload, which is in violation of the WebSocket Spec (See RFC6455 Section 5.5), which limits Control Frames to only 125 bytes of payload.
The maxTextMessageSize only applies to the overall collected message size from Data Frames (TEXT, and 0 or more CONTINUATION frames)
Related
I'm trying to switch from a legacy jms broker to ActiveMQ.
One thing I cannot figure out is a warning in the logs once per hour:
WARN | Transport Connection to: tcp://127.0.0.1:38542 failed: java.io.IOException:
Frame size of 1 GB larger than max allowed 100 MB | ...
It's obviously some scheduled job in ActiveMQ that outputs this warning,
because it comes at the same minute every hour,
regardless of whether any messages are sent or not.
But what exactly means "Frame size" here?
We are not sending any jms-messages larger than a few kilobytes or so...
I read you can increase this "maxFramesize" in the connector, but doesn't help either.
When I try set it to 1GB (1073741824) (or higher) :
<transportConnector name="openwire"
uri="tcp://0.0.0.0:61616?maximumConnections=100&wireFormat.maxFrameSize=1073741824"/>
I still see the (now absurd) warning-message:
WARN | Transport Connection to: tcp://127.0.0.1:42256 failed: java.io.IOException:
Frame size of 1 GB larger than max allowed 1 GB
What is ActiveMQ actually complaining about?
And how can I fix it?
ActiveMQ 5 would only log this message if someone was sending your broker a message that is encoded to a size larger than the configured limit. Since it happens to you on a regular interval then I'd look for some external resource that is doing something silly like trying to telnet into the broker Openwire port to check liveness and sending some garbage string or some such. The broker would not be logging that error unless something was inbound so you need to start looking for the source of the errant sender.
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?
We are running JMeter for connecting TCP Socket thorugh BinaryTCPClientImpl , We are getting the response code : 500
Response message: org.apache.jmeter.protocol.tcp.sampler.ReadException
JMeter Version : 2.9
Help out
If this is the error
ERROR - jmeter.protocol.tcp.sampler.TCPSampler: org.apache.jmeter.protocol.tcp.sampler.ReadException:
at org.apache.jmeter.protocol.tcp.sampler.BinaryTCPClientImpl.read(BinaryTCPClientImpl.java:140)
at org.apache.jmeter.protocol.tcp.sampler.TCPSampler.sample(TCPSampler.java:414)
at org.apache.jmeter.threads.JMeterThread.process_sampler(JMeterThread.java:429)
at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:257)
at java.lang.Thread.run(Unknown Source)
then you have 2 options. The first (and much easier if it applies
to you) is to use the LengthPrefixedBinaryTCPClientImpl. If this
applies to you, that is, if your responses are always the same fixed
sizes, you can simply set the tcp.binarylength.prefix.length property
and go about your business.
If that is not the case, then your other option is to extend
org.apache.jmeter.protocol.tcp.sampler.TCPClient. It may help to get in
touch with the client team of this proprietary protocol, because after
all, they have implemented something that works. You'll probably have
to extend it to look something like LengthPrefixedBinaryTCPClientImpl
read N bytes. Although, this runs the risks of reading too many or too
few bytes. If your application server ever miscalculates the size of
it's output, you suffer the consequences by getting another timeout or
leaving extra bytes in the buffer and reading them on the next iteration
(and then cascading errors).
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'