I tried to make an analogue nc (netcat) tool.
Open file and send it in to TCP socket.
client (sender) side
procedure TForm1.SpeedButton3Click(Sender: TObject);
var Client:TTCPBlockSocket;
FS: TFileStream;
begin
Client:=TTCPBlockSocket.Create;
Client.RaiseExcept:=True;
Client.Connect('192.168.1.95','9999');
FS:=TFileStream.Create('/tmp/test_print.pdf',fmOpenRead);
FS.Position:=0;
Client.SendStream(FS);
FS.Free;
Client.CloseSocket;
Client.Free;
end;
server (reciever) side
nc -l 192.168.1.95 9999 > test.pdf
After run i get test.pdf but md5sum not valid
fe2e5d86acd267ca39a9c15c456e1be0 /tmp/test_print.pdf
34d755aa81d72f525a5e691e98bed283 test.pdf
size is differ too
-rw-rw---- 1 user1 DomainUsers 46444 Июн 8 17:11 /tmp/test_print.pdf
-rw-r--r-- 1 user1 DomainUsers 46448 Июн 11 15:40 test.pdf
What i do wrong? Where is my mistake?
p.s. Excess 4 bytes at the beginning of test.pdf (6c,b5,00,00)
[user1#pandora6 /tmp]$ hexdump -C test.pdf | head -5
00000000 6c b5 00 00 25 50 44 46 2d 31 2e 34 0a 25 c7 ec |l...%PDF-1.4.%..|
00000010 8f a2 0a 34 20 30 20 6f 62 6a 0a 3c 3c 2f 4c 69 |...4 0 obj.<</Li|
00000020 6e 65 61 72 69 7a 65 64 20 31 2f 4c 20 34 36 34 |nearized 1/L 464|
00000030 34 34 2f 48 5b 20 34 33 39 36 38 20 31 34 32 5d |44/H[ 43968 142]|
00000040 2f 4f 20 36 2f 45 20 34 33 39 36 38 2f 4e 20 31 |/O 6/E 43968/N 1|
[user1#pandora6 /tmp]$ hexdump -C /tmp/test_print.pdf | head -5
00000000 25 50 44 46 2d 31 2e 34 0a 25 c7 ec 8f a2 0a 34 |%PDF-1.4.%.....4|
00000010 20 30 20 6f 62 6a 0a 3c 3c 2f 4c 69 6e 65 61 72 | 0 obj.<</Linear|
00000020 69 7a 65 64 20 31 2f 4c 20 34 36 34 34 34 2f 48 |ized 1/L 46444/H|
00000030 5b 20 34 33 39 36 38 20 31 34 32 5d 2f 4f 20 36 |[ 43968 142]/O 6|
00000040 2f 45 20 34 33 39 36 38 2f 4e 20 31 2f 54 20 34 |/E 43968/N 1/T 4|
Well... Hex 00 00 B5 6C (your extra bytes in reverse) is equal to 46444. So my guess is that TFileStream or SendStream sends the number of bytes it wants to send before the actual data.
Looking at the code of Synapse there is the function:
procedure TBlockSocket.InternalSendStream(const Stream: TStream; WithSize, Indy: boolean);
And SendStream calls it like this:
InternalSendStream(Stream, true, false);
So the WithSize is true and the size of the stream is send before the actual data.
If you use SendStreamRaw all is send without the size in front of it.
procedure TForm1.SpeedButton3Click(Sender: TObject);
var Client:TTCPBlockSocket;
FS: TFileStream;
begin
Client:=TTCPBlockSocket.Create;
Client.RaiseExcept:=True;
Client.Connect('192.168.1.95','9999');
FS:=TFileStream.Create('/tmp/test_print.pdf',fmOpenRead);
FS.Position:=0;
Client.SendStreamRAW(FS);
FS.Free;
Client.CloseSocket;
Client.Free;
end;
Related
I understand the shape of the bytes behind a PACKED-DECIMAL number when on a Big-Endian machine. What I have not been able to discover is what shape would those bytes take on a Little-Endian machine.
Note: The reason I believe there does exist a separate format for such is because the IBM MQ Encoding field has the following values:-
MQENC_DECIMAL_NORMAL
MQENC_DECIMAL_REVERSED
Of MQENC_DECIMAL_REVERSED it simply says:-
Packed-decimal integers are represented in the same way as MQENC_DECIMAL_NORMAL, but with the bytes arranged in reverse order. The bits within each byte are arranged in the same way as MQENC_DECIMAL_NORMAL.
Can anyone corroborate or refute this description?
For example, the number +123.45 stored in a PIC 9(3)V99 COMP-3 would have the following bytes:-
12 34 5C
The above quote suggests to me that if in reversed, the same packed decimal number would be represented on a Little-Endian machine as:-
5C 34 12
N.B. I have not tagged this question with ibm-mq, as I don't really think the crux of my question has anything to do with IBM MQ. It is simply the reason I am asking.
It looks like packed data is stored in "normal" byte order.
The following program was compiled with OpenCOBOL 1.1.0 on Ubuntu 16.04 on a Lenovo ThinkPad...
ID Division.
Program-ID. testcmp3.
Environment Division.
Input-Output Section.
File-Control.
Select OUTPUT01 Assign To './output01'
Status OUTPUT01-STATUS.
Data Division.
File Section.
FD OUTPUT01
Record 16
Block 0
Recording F.
01 OUTPUT01-REC PIC X(016).
Working-Storage Section.
01 CONSTANTS.
05 MYNAME PIC X(008) VALUE 'testcmp3'.
01 WS-OUTPUT01-REC.
05 WS-OUT-S94COMP PIC S9(004) COMP VALUE +0.
05 FILLER PIC X(001) VALUE HIGH-VALUES.
05 WS-OUT-S95COMP3 PIC S9(005) COMP-3 VALUE +0.
05 FILLER PIC X(008) VALUE SPACES.
01 WORK-AREAS.
05 OUTPUT01-STATUS PIC X(002) VALUE ZEROES.
Procedure Division.
OPEN OUTPUT OUTPUT01
IF OUTPUT01-STATUS NOT = '00'
DISPLAY
MYNAME
' open of OUTPUT01 status = '
OUTPUT01-STATUS
END-IF
PERFORM 100-WRITE 100 TIMES
CLOSE OUTPUT01
STOP RUN.
100-WRITE.
WRITE OUTPUT01-REC FROM WS-OUTPUT01-REC
ADD 1 TO WS-OUT-S94COMP
ADD 1 TO WS-OUT-S95COMP3
.
...with the option binary-byteorder set to native.
The resulting file, displayed with the hexdump program, follows.
00000000 00 00 ff 00 00 0c 20 20 20 20 20 20 20 20 20 20 |...... |
00000010 01 00 ff 00 00 1c 20 20 20 20 20 20 20 20 20 20 |...... |
00000020 02 00 ff 00 00 2c 20 20 20 20 20 20 20 20 20 20 |....., |
00000030 03 00 ff 00 00 3c 20 20 20 20 20 20 20 20 20 20 |.....< |
00000040 04 00 ff 00 00 4c 20 20 20 20 20 20 20 20 20 20 |.....L |
00000050 05 00 ff 00 00 5c 20 20 20 20 20 20 20 20 20 20 |.....\ |
00000060 06 00 ff 00 00 6c 20 20 20 20 20 20 20 20 20 20 |.....l |
00000070 07 00 ff 00 00 7c 20 20 20 20 20 20 20 20 20 20 |.....| |
00000080 08 00 ff 00 00 8c 20 20 20 20 20 20 20 20 20 20 |...... |
00000090 09 00 ff 00 00 9c 20 20 20 20 20 20 20 20 20 20 |...... |
000000a0 0a 00 ff 00 01 0c 20 20 20 20 20 20 20 20 20 20 |...... |
000000b0 0b 00 ff 00 01 1c 20 20 20 20 20 20 20 20 20 20 |...... |
000000c0 0c 00 ff 00 01 2c 20 20 20 20 20 20 20 20 20 20 |....., |
000000d0 0d 00 ff 00 01 3c 20 20 20 20 20 20 20 20 20 20 |.....< |
000000e0 0e 00 ff 00 01 4c 20 20 20 20 20 20 20 20 20 20 |.....L |
000000f0 0f 00 ff 00 01 5c 20 20 20 20 20 20 20 20 20 20 |.....\ |
00000100 10 00 ff 00 01 6c 20 20 20 20 20 20 20 20 20 20 |.....l |
00000110 11 00 ff 00 01 7c 20 20 20 20 20 20 20 20 20 20 |.....| |
00000120 12 00 ff 00 01 8c 20 20 20 20 20 20 20 20 20 20 |...... |
00000130 13 00 ff 00 01 9c 20 20 20 20 20 20 20 20 20 20 |...... |
00000140 14 00 ff 00 02 0c 20 20 20 20 20 20 20 20 20 20 |...... |
00000150 15 00 ff 00 02 1c 20 20 20 20 20 20 20 20 20 20 |...... |
00000160 16 00 ff 00 02 2c 20 20 20 20 20 20 20 20 20 20 |....., |
00000170 17 00 ff 00 02 3c 20 20 20 20 20 20 20 20 20 20 |.....< |
00000180 18 00 ff 00 02 4c 20 20 20 20 20 20 20 20 20 20 |.....L |
00000190 19 00 ff 00 02 5c 20 20 20 20 20 20 20 20 20 20 |.....\ |
000001a0 1a 00 ff 00 02 6c 20 20 20 20 20 20 20 20 20 20 |.....l |
000001b0 1b 00 ff 00 02 7c 20 20 20 20 20 20 20 20 20 20 |.....| |
000001c0 1c 00 ff 00 02 8c 20 20 20 20 20 20 20 20 20 20 |...... |
000001d0 1d 00 ff 00 02 9c 20 20 20 20 20 20 20 20 20 20 |...... |
000001e0 1e 00 ff 00 03 0c 20 20 20 20 20 20 20 20 20 20 |...... |
000001f0 1f 00 ff 00 03 1c 20 20 20 20 20 20 20 20 20 20 |...... |
00000200 20 00 ff 00 03 2c 20 20 20 20 20 20 20 20 20 20 | ...., |
00000210 21 00 ff 00 03 3c 20 20 20 20 20 20 20 20 20 20 |!....< |
00000220 22 00 ff 00 03 4c 20 20 20 20 20 20 20 20 20 20 |"....L |
00000230 23 00 ff 00 03 5c 20 20 20 20 20 20 20 20 20 20 |#....\ |
00000240 24 00 ff 00 03 6c 20 20 20 20 20 20 20 20 20 20 |$....l |
00000250 25 00 ff 00 03 7c 20 20 20 20 20 20 20 20 20 20 |%....| |
00000260 26 00 ff 00 03 8c 20 20 20 20 20 20 20 20 20 20 |&..... |
00000270 27 00 ff 00 03 9c 20 20 20 20 20 20 20 20 20 20 |'..... |
00000280 28 00 ff 00 04 0c 20 20 20 20 20 20 20 20 20 20 |(..... |
00000290 29 00 ff 00 04 1c 20 20 20 20 20 20 20 20 20 20 |)..... |
000002a0 2a 00 ff 00 04 2c 20 20 20 20 20 20 20 20 20 20 |*...., |
000002b0 2b 00 ff 00 04 3c 20 20 20 20 20 20 20 20 20 20 |+....< |
000002c0 2c 00 ff 00 04 4c 20 20 20 20 20 20 20 20 20 20 |,....L |
000002d0 2d 00 ff 00 04 5c 20 20 20 20 20 20 20 20 20 20 |-....\ |
000002e0 2e 00 ff 00 04 6c 20 20 20 20 20 20 20 20 20 20 |.....l |
000002f0 2f 00 ff 00 04 7c 20 20 20 20 20 20 20 20 20 20 |/....| |
00000300 30 00 ff 00 04 8c 20 20 20 20 20 20 20 20 20 20 |0..... |
00000310 31 00 ff 00 04 9c 20 20 20 20 20 20 20 20 20 20 |1..... |
00000320 32 00 ff 00 05 0c 20 20 20 20 20 20 20 20 20 20 |2..... |
00000330 33 00 ff 00 05 1c 20 20 20 20 20 20 20 20 20 20 |3..... |
00000340 34 00 ff 00 05 2c 20 20 20 20 20 20 20 20 20 20 |4...., |
00000350 35 00 ff 00 05 3c 20 20 20 20 20 20 20 20 20 20 |5....< |
00000360 36 00 ff 00 05 4c 20 20 20 20 20 20 20 20 20 20 |6....L |
00000370 37 00 ff 00 05 5c 20 20 20 20 20 20 20 20 20 20 |7....\ |
00000380 38 00 ff 00 05 6c 20 20 20 20 20 20 20 20 20 20 |8....l |
00000390 39 00 ff 00 05 7c 20 20 20 20 20 20 20 20 20 20 |9....| |
000003a0 3a 00 ff 00 05 8c 20 20 20 20 20 20 20 20 20 20 |:..... |
000003b0 3b 00 ff 00 05 9c 20 20 20 20 20 20 20 20 20 20 |;..... |
000003c0 3c 00 ff 00 06 0c 20 20 20 20 20 20 20 20 20 20 |<..... |
000003d0 3d 00 ff 00 06 1c 20 20 20 20 20 20 20 20 20 20 |=..... |
000003e0 3e 00 ff 00 06 2c 20 20 20 20 20 20 20 20 20 20 |>...., |
000003f0 3f 00 ff 00 06 3c 20 20 20 20 20 20 20 20 20 20 |?....< |
00000400 40 00 ff 00 06 4c 20 20 20 20 20 20 20 20 20 20 |#....L |
00000410 41 00 ff 00 06 5c 20 20 20 20 20 20 20 20 20 20 |A....\ |
00000420 42 00 ff 00 06 6c 20 20 20 20 20 20 20 20 20 20 |B....l |
00000430 43 00 ff 00 06 7c 20 20 20 20 20 20 20 20 20 20 |C....| |
00000440 44 00 ff 00 06 8c 20 20 20 20 20 20 20 20 20 20 |D..... |
00000450 45 00 ff 00 06 9c 20 20 20 20 20 20 20 20 20 20 |E..... |
00000460 46 00 ff 00 07 0c 20 20 20 20 20 20 20 20 20 20 |F..... |
00000470 47 00 ff 00 07 1c 20 20 20 20 20 20 20 20 20 20 |G..... |
00000480 48 00 ff 00 07 2c 20 20 20 20 20 20 20 20 20 20 |H...., |
00000490 49 00 ff 00 07 3c 20 20 20 20 20 20 20 20 20 20 |I....< |
000004a0 4a 00 ff 00 07 4c 20 20 20 20 20 20 20 20 20 20 |J....L |
000004b0 4b 00 ff 00 07 5c 20 20 20 20 20 20 20 20 20 20 |K....\ |
000004c0 4c 00 ff 00 07 6c 20 20 20 20 20 20 20 20 20 20 |L....l |
000004d0 4d 00 ff 00 07 7c 20 20 20 20 20 20 20 20 20 20 |M....| |
000004e0 4e 00 ff 00 07 8c 20 20 20 20 20 20 20 20 20 20 |N..... |
000004f0 4f 00 ff 00 07 9c 20 20 20 20 20 20 20 20 20 20 |O..... |
00000500 50 00 ff 00 08 0c 20 20 20 20 20 20 20 20 20 20 |P..... |
00000510 51 00 ff 00 08 1c 20 20 20 20 20 20 20 20 20 20 |Q..... |
00000520 52 00 ff 00 08 2c 20 20 20 20 20 20 20 20 20 20 |R...., |
00000530 53 00 ff 00 08 3c 20 20 20 20 20 20 20 20 20 20 |S....< |
00000540 54 00 ff 00 08 4c 20 20 20 20 20 20 20 20 20 20 |T....L |
00000550 55 00 ff 00 08 5c 20 20 20 20 20 20 20 20 20 20 |U....\ |
00000560 56 00 ff 00 08 6c 20 20 20 20 20 20 20 20 20 20 |V....l |
00000570 57 00 ff 00 08 7c 20 20 20 20 20 20 20 20 20 20 |W....| |
00000580 58 00 ff 00 08 8c 20 20 20 20 20 20 20 20 20 20 |X..... |
00000590 59 00 ff 00 08 9c 20 20 20 20 20 20 20 20 20 20 |Y..... |
000005a0 5a 00 ff 00 09 0c 20 20 20 20 20 20 20 20 20 20 |Z..... |
000005b0 5b 00 ff 00 09 1c 20 20 20 20 20 20 20 20 20 20 |[..... |
000005c0 5c 00 ff 00 09 2c 20 20 20 20 20 20 20 20 20 20 |\...., |
000005d0 5d 00 ff 00 09 3c 20 20 20 20 20 20 20 20 20 20 |]....< |
000005e0 5e 00 ff 00 09 4c 20 20 20 20 20 20 20 20 20 20 |^....L |
000005f0 5f 00 ff 00 09 5c 20 20 20 20 20 20 20 20 20 20 |_....\ |
00000600 60 00 ff 00 09 6c 20 20 20 20 20 20 20 20 20 20 |`....l |
00000610 61 00 ff 00 09 7c 20 20 20 20 20 20 20 20 20 20 |a....| |
00000620 62 00 ff 00 09 8c 20 20 20 20 20 20 20 20 20 20 |b..... |
00000630 63 00 ff 00 09 9c 20 20 20 20 20 20 20 20 20 20 |c..... |
00000640
The draft standard document ISO/IEC CD2.1 1989:202x says of the USAGE PACKED-DECIMAL phrase...
The USAGE PACKED-DECIMAL clause specifies that a radix of 10 is used
to represent a numeric item in the storage of the computer.
Furthermore, this clause specifies that each digit position shall
occupy the minimum possible configuration in computer storage. Each
implementor specifies the precise effect of the USAGE PACKED-DECIMAL
clause upon the alignment and representation of the data item in the
storage of the computer, including the representation of any algebraic
sign. Sufficient computer storage shall be allocated by the
implementor to contain the maximum range of values implied by the
associated decimal picture character-string. If the WITH NO SIGN
phrase is specified the representation of the data item in the storage
of the computer reserves no storage for representing any sign value.
The PICTURE character string of the data item shall not contain the
symbol ‘S’; the data item is always considered to have a zero, or
positive value.
CoreData: sql:
SELECT t0.Z_ENT, t0.Z_PK, t0.Z_OPT, t0.ZCLIENTCREATEDAT, t0.ZCLIENTUPDATEDAT, t0.ZCREATEDAT, t0.ZDATERAISED, t0.ZID, t0.ZLOCKVERSION, t0.ZNAME, t0.ZSEQUENCENUMBER, t0.ZTYPE, t0.ZUPDATEDAT, t0.ZUUID, t0.ZVSYNCSTATUS, t0.ZVVERSION, t0.ZVVERSIONSTATUS, t0.ZCREATEDBY, t0.ZDATA, t0.ZOWNEDBY, t0.ZPROJECT, t0.ZPROJECTCOMPANY, t0.ZTEMPLATE, t0.ZWBSITEM, t0.ZACTIONTYPE, t0.ZSTATUS, t0.ZCOMPANY, t0.ZCLOSEDREASON, t0.ZDOCUMENTDATA, t0.ZSMARKWHENREADYTOSEND, t0.ZSPDFSYNCSTATUS, t0.ZSTATUS1, t0.ZAUTHORISATIONCODE, t0.ZBCCRECEIVED, t0.ZRECIPIENTEMAIL, t0.ZRECIPIENTNAME, t0.ZRFIRESPONSESTATUS
FROM ZBASEFORM t0
WHERE ((( t0.ZVVERSIONSTATUS = ? OR ( t0.ZVVERSIONSTATUS = ? AND t0.ZVSYNCSTATUS = ?) OR ( t0.ZVVERSIONSTATUS = ? AND t0.ZVSYNCSTATUS = ?)) AND t0.ZPROJECT = ?) AND t0.Z_ENT = ?)
ORDER BY t0.ZDATERAISED DESC, t0.ZCLIENTCREATEDAT DESC
CoreData: annotation: sql connection fetch time: 1.7336s
CoreData: annotation: total fetch execution time: 1.7462s for 1868 rows.
The table has only 1975 rows and I am fetching 1868 of them.
I copied the database from device to desktop and did sqlite> EXPLAIN SELECT ... and got this beast.
addr opcode p1 p2 p3 p4 p5 comment
---- ------------- ---- ---- ---- ------------- -- -------------
0 Init 0 105 0 00
1 SorterOpen 1 40 0 k(2,-B,-B) 00
2 OpenRead 0 8 0 37 00
3 OpenRead 2 76 0 k(2,,) 02
4 Integer 7 1 0 00
5 SeekGE 2 60 1 1 00
6 IdxGT 2 60 1 1 00
7 Seek 2 0 0 00
8 Column 0 8 2 00
9 Eq 3 16 2 (BINARY) 44
10 Ne 5 13 2 (BINARY) 54
11 Column 0 6 4 00
12 Eq 6 16 4 (BINARY) 44
13 Ne 5 59 2 (BINARY) 54
14 Column 0 6 4 00
15 Ne 7 59 4 (BINARY) 54
16 Column 0 12 4 00
17 Ne 8 59 4 (BINARY) 54
18 Column 2 0 11 00
19 IdxRowid 2 12 0 00
20 Column 0 2 13 00
21 Column 0 24 14 00
22 Column 0 25 15 00
23 Column 0 26 16 00
24 Column 0 27 17 00
25 Column 0 3 18 00
26 Column 0 4 19 00
27 Column 0 29 20 00
28 Column 0 5 21 00
29 Column 0 30 22 00
30 Column 0 28 23 00
31 Column 0 31 24 00
32 Column 0 6 25 00
33 Column 0 7 26 00
34 Column 0 8 27 00
35 Column 0 9 28 00
36 Column 0 10 29 00
37 Column 0 11 30 00
38 Column 0 12 31 00
39 Column 0 13 32 00
40 Column 0 14 33 00
41 Column 0 15 34 00
42 Column 0 32 35 00
43 Column 0 16 36 00
44 Column 0 17 37 00
45 Column 0 18 38 00
46 Column 0 36 39 00
47 Column 0 19 40 00
48 Column 0 20 41 00
49 Column 0 21 42 00
50 Column 0 33 43 00
51 Column 0 22 44 00
52 Column 0 34 45 00
53 Column 0 35 46 00
54 Column 0 23 47 00
55 Copy 17 9 0 00
56 Copy 14 10 0 00
57 MakeRecord 9 39 48 00
58 SorterInsert 1 48 0 00
59 Next 2 6 1 00
60 Close 0 0 0 00
61 Close 2 0 0 00
62 OpenPseudo 3 49 40 00
63 SorterSort 1 104 0 00
64 SorterData 1 49 3 00
65 Column 3 2 11 00
66 Column 3 3 12 00
67 Column 3 4 13 00
68 Column 3 5 14 00
69 Column 3 6 15 00
70 Column 3 7 16 00
71 Column 3 8 17 00
72 Column 3 9 18 00
73 Column 3 10 19 00
74 Column 3 11 20 00
75 Column 3 12 21 00
76 Column 3 13 22 00
77 Column 3 14 23 00
78 Column 3 15 24 00
79 Column 3 16 25 00
80 Column 3 17 26 00
81 Column 3 18 27 00
82 Column 3 19 28 00
83 Column 3 20 29 00
84 Column 3 21 30 00
85 Column 3 22 31 00
86 Column 3 23 32 00
87 Column 3 24 33 00
88 Column 3 25 34 00
89 Column 3 26 35 00
90 Column 3 27 36 00
91 Column 3 28 37 00
92 Column 3 29 38 00
93 Column 3 30 39 00
94 Column 3 31 40 00
95 Column 3 32 41 00
96 Column 3 33 42 00
97 Column 3 34 43 00
98 Column 3 35 44 00
99 Column 3 36 45 00
100 Column 3 37 46 00
101 Column 3 38 47 00
102 ResultRow 11 37 0 00
103 SorterNext 1 64 0 00
104 Halt 0 0 0 00
105 Transaction 0 0 188 0 01
106 TableLock 0 8 0 ZBASEFORM 00
107 Integer 1 3 0 00
108 Integer 2 5 0 00
109 Integer 4 6 0 00
110 Integer 5 7 0 00
111 Integer 3 8 0 00
112 Goto 0 1 0 00
I figured out the cause of the slowness.
One of the object properties was a NSData blob which apparently absolutely kills fetch sorting in CoreData. So watch out for that.
I'm trying to decode an AMF0 message with AMF3 included .. All is well
except making sense of the U29 format and the way string are encoded
in AMF4
channel=3 size=134 pkttype=0x11 time=1973
00000: 00 02 00 14 73 65 6E 64 55 6E 69 76 65 72 73 61 6C 4D 65 73 ....sendUniversalMes
00020: 73 61 67 65 00 00 00 00 00 00 00 00 00 05 02 00 11 6D 62 5F sage.............mb_
00040: 31 32 32 31 30 5F 37 35 39 32 33 33 38 30 05 00 40 58 C0 00 12210_75923380..#X..
00060: 00 00 00 00 11 0A 0B 01 09 68 62 69 64 04 81 CF 5E 09 73 72 .........hbid...^.sr
00080: 63 65 06 49 63 37 62 39 32 33 65 65 2D 30 61 30 38 2D 34 62 ce.Ic7b923ee-0a08-4b
00100: 61 32 2D 38 65 37 63 2D 63 38 32 61 39 33 64 37 37 31 34 32 a2-8e7c-c82a93d77142
00120: 09 68 62 64 6C 04 00 09 74 65 78 74 01 01 .hbdl...text..
first byte I skip
02 = string
00 14 = length of string ( 20 characters , sendUniversalMessage )
00 00 00 00 00 00 00 00 00 = number = 0
05 = null
02 = string
00 11 = length of string ( 17 characters , mb_12210_75923380 )
05 = null
00 40 58 C0 00 00 00 00 00 = number = 99
11 = AMV+
here is where I have problems
0A = AMF3 object
now I need to do a readU29 which starts with
0B = what does this mean
01 = what does this mean
09 = what does this mean
where is the length of the string 'hbid' ?
in U29, if the first byte is worth less than 128, it fits on the first byte. So you have to read this as 3 different u29s, worth 0B, 01, 09.
0B: details about the type of object. It seems you're not too interested in that byte and it's complicated, so pass.
01: The LSB is the bit that says that this isn't a string reference. Then 01 >> 1 = 0 is the length of the class name. This means empty string, which means this is an anonymous (untyped) object.
09: = 00001001. The LSB is also the bit that says this isn't a string reference. Then 1001 >> 1 = 0100 = 4 is the string length.
hope that helps
i want to find the size of running application of blackberry by code.I checked the how to find application size in blackberry by code? link but i am not getting answer. Please suggest me solution. Thanks in advance.
If you mean of size of running application that size of total cod files
then we can calculate.
when we instal application using JAD we can see the application size.
For example: my application name is PictureBackground
After successful sign in application we can take cod fils and jad file for devise installation. when we click on PictureBackground.jad then we can find following type of information
Name: PictureBackground
Version: 1.0.0
Vender: Blackberry Developer
Size: 513.4kb
If you want to pragmatically retrieve that size, then we can do it as following
we can find all information about application in PictureBackground.jad file
For example PictureBackground.jad file as follow:
RIM-COD-SHA1-4: ff 3c 2f ec 7b 6a 3d 1a e3 86 ec d2 87 0a c3 e1 6c f3 14 0e
RIM-COD-SHA1-3: 07 4d f7 db 9a f3 df 1d 00 90 b6 4f 54 f0 3a f0 c8 de ca b1
RIM-COD-SHA1-2: 95 14 4a 6a 7d 3a 1b db 2e 0f 05 b8 e1 ff 66 8a e0 ce f1 64
RIM-COD-SHA1-1: 68 a7 09 4e dc cf 2f c1 9b 43 d1 0b 35 b8 4b bc 35 72 ba 92
RIM-MIDlet-Flags-1: 0
MIDlet-Jar-Size: 591513
MIDlet-Name: PictureBackground
MIDlet-Jar-URL: PictureBackground.jar
MicroEdition-Configuration: CLDC-1.1
RIM-COD-URL-9: PictureBackground-9.cod
RIM-COD-URL-8: PictureBackground-8.cod
RIM-COD-URL-7: PictureBackground-7.cod
RIM-COD-Module-Dependencies: net_rim_cldc
RIM-COD-URL-6: PictureBackground-6.cod
RIM-COD-URL-5: PictureBackground-5.cod
RIM-COD-URL-4: PictureBackground-4.cod
RIM-COD-URL-3: PictureBackground-3.cod
RIM-COD-URL-2: PictureBackground-2.cod
RIM-COD-URL-1: PictureBackground-1.cod
RIM-COD-Size-9: 51288
RIM-COD-Size-8: 55284
RIM-COD-Size-7: 58560
RIM-COD-Size-6: 51340
RIM-COD-Size-5: 55748
RIM-COD-Size-4: 53000
RIM-COD-Size-3: 55084
RIM-COD-Module-Name: PictureBackground
RIM-COD-Size-2: 51284
RIM-COD-Size-1: 60448
RIM-COD-SHA1: 55 82 db c2 8c 44 73 c8 44 b6 ce 7f 20 bb 70 47 d2 df fe ab
RIM-COD-Size: 33688
MicroEdition-Profile: MIDP-2.0
MIDlet-Vendor: BlackBerry Developer
MIDlet-1: PictureBackground,,
RIM-COD-URL: PictureBackground.cod
Manifest-Version: 1.0
MIDlet-Version: 1.0.0
RIM-COD-SHA1-9: 76 04 75 59 21 27 c6 18 97 ed 49 fb ce 03 f3 21 fd 63 c1 96
RIM-COD-SHA1-8: 79 a9 b7 85 59 aa 06 e6 4b 76 89 de 12 cd 10 0d 54 93 48 dd
RIM-COD-SHA1-7: 3d d1 d1 47 e3 8d b5 9d 57 89 51 e3 a9 b3 77 5e c4 57 17 a8
RIM-COD-Creation-Time: 1327931490
RIM-COD-SHA1-6: f7 78 f7 b3 46 f5 69 91 9d 87 33 d0 a9 9d 9b 92 b6 de 90 74
RIM-COD-SHA1-5: 98 b3 45 64 8b 5f 36 0a aa c1 0e 2e 66 ea 7a f7 50 37 05 7a
Through this we can find the running application size
Sample code :
package samplecode;
import java.util.Enumeration;
import net.rim.device.api.system.ApplicationDescriptor;
import net.rim.device.api.system.CodeModuleGroup;
import net.rim.device.api.system.CodeModuleGroupManager;
import net.rim.device.api.ui.UiApplication;
import net.rim.device.api.ui.component.LabelField;
import net.rim.device.api.ui.container.MainScreen;
public class StartUp extends UiApplication{
public static void main(String[] args) {
StartUp up=new StartUp();
up.enterEventDispatcher();
}
public StartUp()
{
MainScreen screen=new MainScreen();
CodeModuleGroup cmg = null;
CodeModuleGroup[] allGroups = CodeModuleGroupManager.loadAll();
String moduleName = ApplicationDescriptor.currentApplicationDescriptor().getModuleName();
for (int i = 0; i < allGroups.length; i++) {
if (allGroups[i].containsModule(moduleName)) {
cmg = allGroups[i];
break;
}
}
if (cmg == null) {
screen.add(new LabelField("not able to fetch properties"));
} else {
double size=0;
for (Enumeration e = cmg.getPropertyNames(); e
.hasMoreElements();) {
String name = (String) e.nextElement();
String value = cmg.getProperty(name);
if(name.indexOf("RIM-COD-Size")!=-1)
{
size=size+Double.parseDouble(value);
}
//add(new LabelField("Name: " + name));
}
screen.add(new LabelField("Size: " +(size/1024)+"kb"));
}
UiApplication.getUiApplication().pushScreen(screen);
}
}
NOTE: IT WONT WORK ON SIMULATOR, IT WORKS ON DEVISE(IT SHOULD BE INSTALL FROM JAD FILE) AND WE CAN FIND OUTPUT AS FOLLOWING
size:513.40234375KB
I have Chromium 12.0.742.112 (90304) and I'm trying to set up a simple WebSocket server with it. I receive a handshake request like:
Upgrade: WebSocket
Connection: Upgrade
Host: akira:22222
Origin: http://akira:22222
Sec-WebSocket-Key1: ;39LP*eC48 n /r0P6 v6548
Sec-WebSocket-Key2: 1 0 r 362547 4 4 G
followed by 8 key bytes, in this case 88 09 F9 EE 21 13 F4 0D. I've verified that these are the same keys Chromium shows in the Network console tab. I calculate the first two keys as:
Key1: 3948066548 / 4 = 987016637
Key2: 1036254744 / 12 = 86354562
and send my response:
000001 48 54 54 50 2F 31 2E 31 20 31 30 31 20 57 65 62 HTTP/1.1 101 Web
000011 20 53 6F 63 6B 65 74 20 50 72 6F 74 6F 63 6F 6C Socket Protocol
000021 20 48 61 6E 64 73 68 61 6B 65 0D 0A 55 70 67 72 Handshake..Upgr
000031 61 64 65 3A 20 57 65 62 53 6F 63 6B 65 74 0D 0A ade: WebSocket..
000041 43 6F 6E 6E 65 63 74 69 6F 6E 3A 20 55 70 67 72 Connection: Upgr
000051 61 64 65 0D 0A 53 65 63 2D 57 65 62 53 6F 63 6B ade..Sec-WebSock
000061 65 74 2D 4F 72 69 67 69 6E 3A 20 68 74 74 70 3A et-Origin: http:
000071 2F 2F 61 6B 69 72 61 3A 32 32 32 32 32 0D 0A 53 //akira:22222..S
000081 65 63 2D 57 65 62 53 6F 63 6B 65 74 2D 4C 6F 63 ec-WebSocket-Loc
000091 61 74 69 6F 6E 3A 20 77 73 3A 2F 2F 61 6B 69 72 ation: ws://akir
0000A1 61 3A 32 32 32 32 32 2F 73 6F 63 6B 65 74 0D 0A a:22222/socket..
0000B1 0D 0A FF F4 2E 12 9D DC 12 C2 56 40 B8 09 F3 84 ..........V#....
0000C1 CA EF .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..##############
Chromium just closes the socket without even printing a message in the JS console. I can't tell what I'm doing wrong?
The server-side code is in Lua (thus why the above hex dump is indexed starting from 1):
require('crypto')
local handshake = {
"HTTP/1.1 101 Web Socket Protocol Handshake",
"Upgrade: WebSocket",
"Connection: Upgrade",
"Sec-WebSocket-Origin: " .. request.header.origin,
"Sec-WebSocket-Location: " ..
request.header.origin:gsub('http:', 'ws:') .. "/socket",
'\r\n'}
log.debug("Request header:\n%s\n", table.concat(request.rawheader, '\n'))
local client = response.socket
client:settimeout(10)
local keys =
{request.header.sec_websocket_key1, request.header.sec_websocket_key2}
local sum = {}
for i, k in ipairs(keys) do
local nspc = 0
sum[i] = ''
k:gsub('%d', function(n) sum[i] = sum[i] ..n end)
k:gsub(' ', function() nspc = nspc + 1 end)
log.debug("Key%d: %s / %d = ", i, sum[i], nspc)
sum[i] = tostring(tonumber(sum[i]) / nspc)
log.debug("%s\n", sum[i])
end
local key = assert(client:receive(8))
local bytes = {key:byte(1, #key)}
local keydump = {}
for i = 1, #bytes do keydump[i] = ('%02X'):format(bytes[i]) end
log.debug("Key3: %s\n", table.concat(keydump, ' '))
local resp = crypto.evp.digest('md5', table.concat(sum) .. key, true)
handshake = table.concat(handshake, '\r\n') .. resp
client:settimeout(0.1)
log.debug("Send handshake:\n%s\n", rena.debug.hexdump(handshake))
client:send(handshake)
repeat
local res, err = client:receive('*l')
if res then log.debug("R: %s\n", res) end
local res, err = client:send("Test " .. tostring(os.time()) .. '\n')
if res then socket.sleep(1)
elseif err == 'timeout' then log.debug("WS: Timed out\n")
elseif err == 'closed' then log.debug("WS: Closed\n")
else log.error("WS: Error: %s\n", tostring(err))
end
until not res
(This script is loaded by the server script which presets some variables such as request and response, and uses LuaCrypto for MD5). Everything looks right (though I notice all the examples show nice ASCII characters for the binary keys whereas mine are mostly unprintable), but it just closes the socket.
Unfortunately Chromium is the only browser I have that supports WebSocket at all (unless there's some way to enable it in Firefox 6?), so I can't check in anything else.
Well I found the issue. The first two keys are meant to be concatenated as 32-bit integers (into a single 64-bit integer), not as ASCII strings:
- sum[i] = tostring(tonumber(sum[i]) / nspc)
+ sum[i] = ('%08X'):format(tonumber(sum[i]) / nspc)
- local resp = crypto.evp.digest('md5', table.concat(sum) .. key, true)
- handshake = table.concat(handshake, '\r\n') .. resp
+ local challenge = ''
+ (sum[1] .. sum[2]):gsub('..', function(byte)
+ challenge = challenge .. string.char(tonumber(byte, 16))
+ end)
+
+ challenge = challenge .. key
+ log.debug("Ch: %s\n", challenge:tohex())
+
+ local resp = crypto.evp.digest('md5', challenge, true)
+ handshake = table.concat(handshake, '\r\n') .. resp
With that Chromium accepts the connection. I've filed a bug to complain about the lack of error message with an incorrect hash.