How much is the Central writeValue data size limit,
I try send this string
PeripheralModeTest - Demonstrated how to communicate with other iOS Devices via CBPeripheralManager.
When I receive the data , Is divided into three string points three times.
If I send the string length of more than 180, can't send out.
Related
I'm writing an api to an SMS receiving device and one of the fields I see is SCTS - Service Center Timestamp. I've sent an SMS to it at 15:26 UTC and I have the following SCTS: 22082211263196, so the time in this string is 11:26:31, i.e. UTC-4.
I can't make sense of the timezone offset - 96. It's supposed to be the number of quarter-hours + the sign. In binary this value translates to 1100000 so if the first 1 means minus, what remains is 100000 or 32 in decimal, i.e. 32/4 = 8, so UTC-8? Am I missing something? How do I get the correct timezone from SCTS?
I have an EA set in place that loops history trades and builds one large string with trade information. I then send this string every second from MT4 to the python backend using a plain PUSH/PULL pattern.
For whatever reason, the data isn't received on the pull side when the string transferred becomes too long. The backend PULL-socket slices each string and further processes it.
Any chance that the PULL-side is too slow to grab and process all the data which then causes an overflow (so that a delay arises due to the processing part)?
Talking about file sizes we are well below 5kb per second.
This is the PULL-socket, which manipulates the data after receiving it:
while True:
# check 24/7 for available data in the pull socket
try:
msg = zmq_socket.recv_string()
data = msg.split("|")
print(data)
# if data is available and msg is account info, handle as follows
if data[0] == "account_info":
[...]
except zmq.error.Again:
print("\nResource timeout.. please try again.")
sleep(0.000001)
I am a bit curious now since the pull socket seems to not even be able to process a string containing 40 trades with their according information on a single MT4 client - Python connection. I actually planned to set it up to handle more than 5.000 MT4 clients - python backend connections at once.
Q : Any chance that the pull side is too slow to grab and process all the data which then causes an overflow (so that a delay arises due to the processing part)?
Zero chance.
Sending 640 B each second is definitely no showstopper ( 5kb per second - is nowhere near a performance ceiling... )
The posted problem formulation is otherwise undecidable.
Step 1) POSACK/NACK prove whether a PUSH side accepts the payload for sending error-free.
Step 2) prove the PULL side is not to be blamed - [PUSH.send(640*chr(64+i)) for i in range( 10 )] via a python-2-python tcp://-transport-class solo-channel crossing host-to-host hop, over at least your local physical network ( no VMCI/emulated vLAN, no other localhost colocation )
Step 3) if either steps above got POSACK-ed, your next chances are the ZeroMQ configuration space and/or the MT4-based PUSH-side incompatibility, most probably "hidden" inside a (not mentioned) third party ZeroMQ wrapper used / first-party issues with string handling / processing ( which you must have already read about, as it has been so many times observed and mentioned in the past posts about this trouble with well "hidden" MQL4 internal eco-system changes ).
Anyway, stay tuned. ZeroMQ is a sure bet and a truly horsepower for professional and low-latency designs in distributed-system's domain.
I'm using ZeroMQ / ZMQ from Python and Java and have a question. When sending a shorter string, ZMQ uses one byte as described here (http://zguide.zeromq.org/page:all#A-Minor-Note-on-Strings)
Then what goes onto the wire is a length (one byte for shorter
strings) and the string contents as individual characters.
Does anyone know how many bytes are used when sending a longer string?
How many bytes are used for longer string when sending via ZMQ?
That depends on hell more things, than just on the string itself :
Your post refers to indeed historical text - the zguide pages.
While this was sure a very helpful first-read source in the early days of ZeroMQ v.2.x, today, we live with distributed-sysems spanning many versions, from v.2.1+, 3.x, 4.x, 4.2 being so far the last stable API version in 2018-Q2.
No one can a priori guess what API-version was used on the message-sender's side, until a receiver actually sets/accepts the link-setup and .recv()-s the respective message. Relying on a C-lang based s_recv()-helper tricks in post v4.0 API is not a sure direction to follow.
Being in python, many protocol-hardwired details remain beyond your sight, yet there are byte-maps, that get filled under the hood exactly as the benevolent dictatorship, indoctrinated in the published ZeroMQ RFC/ZMTP-specifications, dictates.
If we cannot guess or know beforehand, can we ... ?
Yes, we can experiment. Best setup a controlled distributed-system experiment.
Node A : The Sender
can be pythonic, being a sender:
- setup a REQ-archetype AccessNode ( details in "ZeroMQ Hierarchy in less than a five seconds" ),
- setup .setsockopt( zmq.IDENTITY, ... ) with a randomness-generated static identity,
- setup a .setsockopt( zmq.REQ_RELAXED, 1 ),
- .bind() it to a known endpoint of a transport-class of one's choice
- start an xrange()-generator controlled for L in xrange( 1, int( 1E+9 ) )-loop of .send()-s
- there load a payload .send( r"{0:}|{1:}".format( str( L ), L * r"*" ) )
- handle the respective .recv() for a REP-side "answer",
- check the error-states and adapt the time.sleep()-s / re-loops, according to the sender-side socket capacity and capability to send further payloads
Node B : The Receiver | The MitM-sniffer
ought be as low level as possible, so as to dis-assemble the RFC/ZMTP wire-line protocol, so python gets out of the candidate list. Other option may include a wire-level sniffer(s), if the selected transport-class permits ( an ipc:// or a vmci:// one will not )
setup a ROUTER-archetype AccessNode,
.connect() it to the know Node A's transport-class endpoint used,
start .recv()-ing messages,
If your experiment has correctly acquired / sniffed the wire-level details about the ZMTP-compliant transport sizes of the know payload compositions, your question gets repeatable, verifiable, quantitatively correct records on string-size to message-size mapping-function.
A BONUS POINT: for those indeed interested . . .Next, re-run the controlled white-box distributed-system experiment above, now with having the Node A: The Sender-side extended it's behaviour to also{ randomly | deterministically } { change | alter } its own configuration ( or map both such options onto a pair of the same payload re-.send()-s )with a.setsockopt( zmq.REQ_CORRELATE, { on | off } ) inside its for-loop and record the observed changes in the expected outputs.
This adds a final touch to the definitive answer, as far as the API v.4.2.x permits in the 2018-Q2.
I am trying to get the number of label formats remaining in the print buffer of a Zebra printer. The printer is being accessed using the Zatar cloud service. To achieve this I am:
putting the printer in a paused state
calling the ^HS command
looking at the 5th field in string 1 of the response
According to the ZPL documentation this field is the
number of formats in receive buffer
However, this value does not appear to be correct. Each subsequent time we call it whilst the printer is paused the value in the field increases. No other jobs are being sent to the printer.
Here is same output of the response:
DEVICE_COMPLETED_SUCCESSFULLY - 030,0,1,0834,003,0,0,0,000,0,0,0
000,0,0,0,0,2,6,0,00000001,1,001
1234,0
Then this after a short interval:
DEVICE_COMPLETED_SUCCESSFULLY - 030,0,1,0834,026,0,0,0,000,0,0,0
000,0,0,0,0,2,6,0,00000001,1,001
1234,0
And so on:
DEVICE_COMPLETED_SUCCESSFULLY - 030,0,1,0834,028,0,0,0,000,0,0,0
000,0,0,0,0,2,6,0,00000001,1,001
1234,0
The initial response of 003 is correct. However I do not understand why it is then incrementing to 26 and then to 28.
Why is the response not providing the correct value for the formats remaining in the receive buffer?
The reason for the discrepancy in the number of formats in the receive buffer was due to how the printer was being accessed. The Zatar cloud service was used rather than any direct method such as USB.
The Zatar cloud service uses a device called an Edgebox to communicate with the printer. The Edgebox was periodically sending commands to the printer and it was these commands that were accumulating in the receive buffer.
I'm developing an SMS Gateway and I was thinking about the features that I should implement in it. So I reviewed some SMS gateways (SMSNOW, SMS studio, and Ozeki) for examples.
I almost finished the implementation but I came across a feature in almost all SMS gateways which allows the user to specify TON/NPI for SMSC and ESME.
I understand that when the SMS gateway is preparing to send the sms using the SMPP protocol it would need to parse the sender/reciever number and based on that, specify TON/NPI. And I understand that it's great to allow you to override the defaults and specify your own TON/NPI.
What I don't understand is why all SMS gateways give you the option to specify your own TON/NPI for the SMS gateway when it acts as SMSC (when it receives SMS, not sending them).
What would the SMS gateway do with the specified TON/NPI when it recieves an smpp SMS?
The full specification of an SMS source address involves 3 attributes:
TON
NPI
The actual Address
TON = Type of Number.
This specifies whether the number is a full International Number (i.e. needs the + prefix), or a National Number, or even an alphanumeric sender (i.e. includes up to 11 characters of text instead of a numeric sender, quite useful for advertising).
NPI = Numbering Plan Indicator
This specifies which numbering standard the number is following. It could be the E.164 standard international numbering, or the operator's private numbering (for premium rated services for instance).
The actual Address.
An SMSC would need the TON/NPI to know how to interpret the bytes stored in the Address. If for example the TON is alphanumeric (5), it knows the bytes in the address need to be interpreted as characters and encoded accordingly, while if it is International (1), it would split each byte into 2, with each half byte representing a different digit for the sender.
You can refer to the SMPP 3.4 specification Sections 5.2.5 and 5.2.6 for a full list of these TON/NPI possibilities. The specific SMS gateway you're using might restrict you from using some of them.
TON (Type of Number)
If you wish to specify a special value for the TON, the available options are:
0: Unknown
1: International
2: National
3: Network Specific
4: Subscriber Number
5: Alphanumeric
6: Abbreviated
NPI (Numbering Plan Identification)
For NPI, the available options are:
Unknown = 0
ISDN/telephone numbering plan (E163/E164) = 1
Data numbering plan (X.121) = 3
Telex numbering plan (F.69) = 4
Land Mobile (E.212) =6
National numbering plan = 8
Private numbering plan = 9
ERMES numbering plan (ETSI DE/PS 3 01-3) = 10
Internet (IP) = 13
WAP Client Id (to be defined by WAP Forum) = 18
TON and NPI Defaults
Short Code (3 digits to 8 digits in length)
If the source code/address is a Short Code
TON = 3
NPI = 0
Long Code (10 digits to 15 digits in length, excludes the plus sign)
TON = 1
NPI = 1
Alphanumeric
If the source code/address is Alphanumeric (contains both letters and numbers or only letters)
TON = 5
NPI = 0