What's the point of having continuation opcode? - websocket

Here's an example from MDN:
Client: FIN=1, opcode=0x1, msg="hello"
Server: (process complete message immediately) Hi.
Client: FIN=0, opcode=0x1, msg="and a"
Server: (listening, new message containing text started)
Client: FIN=0, opcode=0x0, msg="happy new"
Server: (listening, payload concatenated to previous message)
Client: FIN=1, opcode=0x0, msg="year!"
Server: (process complete message) Happy new year to you too!
Isn't the FIN bit enough to determine whether the message is finished or to be continued? The continuation opcode looks to be redundant to me.


The opt codes indicate the type of frame. Only the first frame can indicate if it is Text (0x1) or Binary, and control frames cannot be fragmented, so the ausence of any opt code (0x0) means Continuation.
I mean, if you have 4 bits available and you want to send nothing, you put all zeroes (0x0), but you still need to send those four bits.
https://www.rfc-editor.org/rfc/rfc6455#section-5.2

Related

Unable to receive URC for an incoming SMS from a modem

I have an issue in being unable to recive the URC message from the modem whenever it receives an SMS.
I know that it receives them since i can find and read them if I use AT+CMGL but, i don't receive any notification when the modem gets them. I played around with the URC related commands but I've been unable to get it to work (other URCs work fine).
The modem is a BG600L M3 from Quectel and following is the sequence of commands i'm sending ("AT" is always omitted and the first command is literally "AT\r", basically an empty one).
//general config
AT\r
CFUN=1,0
E1
+QCFG=\"urc/ri/other\",\"pulse\",8,1
H0
&F
V1
+CMEE=1
&D0
E1
+CREG=2
+CGREG=2
+CEREG=2
//sms config
+CPMS=\"ME\",\"ME\",\"ME\"
+QINDCFG=\"smsincoming\",1
+CMGF=1
+CSDH=0
+CSCS=\"GSM\"
+CNMI=2,2,0,2,0
//doing some deleting and reading
+CMGD=1,3
+CPMS?
//getting the gps fix
+QGPS=1
+QGPSCFG=\"gnssconfig\",3
+QGPSLOC=1
+QGPSEND
//resetting the gms connection
+CFUN=0
+CFUN=1,0
//setting up the gsm connection
+QICFG=\"dataformat\",0,0
+QICFG=\"viewmode\",0
+QICFG=\"recvind\",1
+QICFG=\"tcp/retranscfg\",3,600
+QISDE=0
+QCFG=\"band\",0xf,0x80085,0x80085,1
+QCFG=\"nwscanmode\",1,1
+QCFG=\"nwscanseq\",010101,1
+QCFG=\"iotopmode\",2,1
// checking if it's connected
+CREG?
+QNWINFO
+COPS?
//Getting the time
+CTZU=3
+CTZR=0
+QLTS
+CCLK?

You can set AT+CNMI=2,1,2,0,0 , that should do the trick.
According to specification ETSI TS 127 005 V11.0.0 (2012-10)
+CNMI: <mode>,<mt>,<bm>,<ds>,<bfr>
by keeping <mt> value to 1 we should get indication when message is stored in ME/TA
<mt>: integer type (the rules for storing received SMs depend on its
data coding scheme
0 No SMS-DELIVER indications are routed to the TE.
1 If SMS-DELIVER is stored into ME/TA, indication of the memory location is routed to the TE using unsolicited result code:
+CMTI: <mem>,<index>

correct way to determine a complete handshake of EAPOL frames

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?

What do the bytes and duration fields in squid log count for https (CONNECT)?

Standard squid config only logs one CONNECT line for any https transaction. What is being counted/timed by the reported bytes and duration fields in that line?

Got an answer via the squid-users mailing list [1]:
Unless you are using SSL-Bump or such to process the contents specially.
The duration is from the CONNECT message arriving to the time TCP close
is used to end the tunnel. The size should be the bytes sent to the
client (excluding the 200 reply message itself) during that time.
[1] http://lists.squid-cache.org/pipermail/squid-users/2016-July/011714.html

ZMQ data transfer latency from one process to another?

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.

APNS response packet returning the wrong identifier

I'm getting an odd error when using APNS under production.
Whenever I send a notification that errors (for example the device token becomes invalid), the response packet returned is correct, except that the identifier is 1 less than the identifier I sent. However, on production the correct identifier is returned.
For example: I send a notification with ID 108. But I receive a packet back:
8 8 0 0 0 107
The first byte will always be 8
The second byte is the status code; in this case meaning the device token isn't valid
The last 4 bytes are the identifier
For convenience, here is Apples documentation on the subject.
http://developer.apple.com/library/ios/#DOCUMENTATION/NetworkingInternet/Conceptual/RemoteNotificationsPG/CommunicatingWIthAPS/CommunicatingWIthAPS.html#//apple_ref/doc/uid/TP40008194-CH101-SW4
Is anyone else seeing this problem, or is it likely something I've done wrong.
Many thanks in advance.

Resources