Hi websocket stream is not working in apple devices. Can I save live stream mp4 for mobile devices.
var nanocon = new WebSocket("wss://bintu-splay.nanocosmos.de/h5live/authstream?url=rtmp%3A%2F%2Fbintu-splay.nanocosmos.de%3A80%2Fsplay&stream="+stream+"&cid=579991&pid=63355099213&expires="+sec.expires+"&tag="+sec.tag+"&token="+sec.token+"&options="+sec.options+"");
nanocon.onmessage = function(onmsg)
{
const dataBuffer = onmsg.data;
const fileStream = Fs.createWriteStream('st/finalvideo.webm', {flags: 'a'});
fileStream.write(dataBuffer);
console.log(dataBuffer);
socket.send(onmsg.data);
}
And response data is
> {"eventType":"onUpdateSourceSuccess","onUpdateSourceSuccess":{"requestId":0,"count":0,"tag":""}}
> {"eventType":"onStreamInfo","onStreamInfo":{"haveVideo":true,"haveAudio":true,"mimeType":"video/mp4; codecs=\"avc1.42E01E, mp4a.40.2\"","prerollDuration":0,"videoInfo":{"width":1280,"height":720,"frameRate":30},"audioInfo":{"sampleRate":48000,"channels":2,"bitsPerSample":16}}}
> <Buffer 00 00 00 24 66 74 79 70 69 73 6f 35 00 00 00 01 61 76 63 31 69 73 6f 35 64 73 6d 73 6d 73 69 78 64 61 73 68 00 00 04 88 6d 6f 6f 76 00 00 00 6c 6d 76 ... >
> {"eventType":"onRandomAccessPoint","onRandomAccessPoint":{"streamTime":0}}
> <Buffer 00 00 00 a8 6d 6f 6f 66 00 00 00 10 6d 66 68 64 00 00 00 00 00 00 00 00 00 00 00 4c 74 72 61 66 00 00 00 10 74 66 68 64 00 02 00 00 00 00 00 01 00 00 ... >
Related
I'm trying to modify buffers, however when modifying them I wish them to be in utf-8 so I attempt to do this via myBuffer.toString('utf8') however if I make no changes and attempt to convert it back via Buffer.from(myBuffer, 'utf8'), I am presented with a completely new buffer on occasions.
These occasions seem to be when parsing an image file, instead of a html file.
My next step was to accept a bug or erroneous behaviour by comparing the two buffers using the following code:
//myBuffer is the buffer is wish to attempt to modify
let testParse = Buffer.from(myBuffer.toString('utf8'), 'utf8');
let editable = Buffer.compare(myBuffer, testParse);
console.log(myBuffer);
console.log(testParse);
console.log(editable);
The following snippet however refuses to work and editable is always -1 here is an example output:
<Buffer 89 50 4e 47 0d 0a 1a 0a 00 00 00 0d 49 48 44 52 00 00 01 10 00 00 00 5c 08 02 00 00 00 29 85 7d e1 00 00 15 31 49 44 41 54 78 01 ed 5d 05 94 db c8 b2 ... >
<Buffer ef bf bd 50 4e 47 0d 0a 1a 0a 00 00 00 0d 49 48 44 52 00 00 01 10 00 00 00 5c 08 02 00 00 00 29 ef bf bd 7d ef bf bd 00 00 15 31 49 44 41 54 78 01 ef ... >
-1
As you can see the buffers are completely different however returns -1
another example where the buffers are both equal:
<Buffer 3c 21 64 6f 63 74 79 70 65 20 68 74 6d 6c 3e 3c 68 74 6d 6c 20 69 74 65 6d 73 63 6f 70 65 3d 22 22 20 69 74 65 6d 74 79 70 65 3d 22 68 74 74 70 3a 2f ... >
<Buffer 3c 21 64 6f 63 74 79 70 65 20 68 74 6d 6c 3e 3c 68 74 6d 6c 20 69 74 65 6d 73 63 6f 70 65 3d 22 22 20 69 74 65 6d 74 79 70 65 3d 22 68 74 74 70 3a 2f ... >
-1
As you can see both buffers are equal and -1 is still returned.
So my question is, what am I doing wrong so that the buffers cannot be compared properly? Any suggestions/criticism are welcome.
You have to compare in the same encoding :
//:Buffer Comparison
const fs = require('fs')
fs.readFile(__dirname+"/test.jpg",(e,buffer)=>{
let testParse = Buffer.from(buffer.toString('utf8'), 'utf8');
let editable = Buffer.compare(buffer, testParse);
console.log("----: wrong method :----")
console.log(buffer);
console.log(testParse);
console.log(editable);
// You have to compare them in the same encoding :
console.log("----: right method :----")
let goodParse = Buffer.from(buffer.toString('utf8'));
let editable2 = goodParse.compare(Buffer.from(buffer.toString('utf8')));
console.log(buffer);
console.log(goodParse);
console.log(editable2);
})
As you can see, we load an image as a buffer, then it is parsed into utf8, so if you modify it, and then want to compare it to the original buffer. Since the modified was parsed to utf8 the original must also be parsed to utf8 in the moment of the comparison.
I hope you understand that explanation.
Console output:
----: wrong method :----
<Buffer ff d8 ff e0 00 10 4a 46 49 46 00 01 01 00 00 01 00 01 00 00 ff db 00 43 00 08 06 06 07 06 05 08 07 07 07 09 09 08 0a 0c 14 0d 0c 0b 0b 0c 19 12 13 0f ... >
<Buffer ef bf bd ef bf bd ef bf bd ef bf bd 00 10 4a 46 49 46 00 01 01 00 00 01 00 01 00 00 ef bf bd ef bf bd 00 43 00 08 06 06 07 06 05 08 07 07 07 09 09 08 ... >
1
----: right method :----
<Buffer ff d8 ff e0 00 10 4a 46 49 46 00 01 01 00 00 01 00 01 00 00 ff db 00 43 00 08 06 06 07 06 05 08 07 07 07 09 09 08 0a 0c 14 0d 0c 0b 0b 0c 19 12 13 0f ... >
<Buffer ef bf bd ef bf bd ef bf bd ef bf bd 00 10 4a 46 49 46 00 01 01 00 00 01 00 01 00 00 ef bf bd ef bf bd 00 43 00 08 06 06 07 06 05 08 07 07 07 09 09 08 ... >
0
My question is how I get python to read a file where the text is in 16bit characters. The rest of the post describes the situation.
I have a text file which is a playlist export from iTunes.
Here is a short section including the header
Name Artist Composer Album Grouping Work Movement Number Movement Count Movement Name Genre Size Time Disc Number Disc Count Track Number Track Count Year Date Modified Date Added Bit Rate Sample Rate Volume Adjustment Kind Equalizer Comments Plays Last Played Skips Last Skipped My Rating
Keyboard Works of the Masters Randolph Hokanson Pan125b 2054816 64 03/11/2017, 18:00 03/11/2017, 17:01 256 44100 MPEG audio file 1 03/11/2017, 17:02 4 08/03/2018, 16:07
08 Traccia 08 11159905 464 03/11/2017, 17:39 03/11/2017, 16:59 192 48000 MPEG audio file 1 03/11/2017, 16:59
09 Traccia 09 17787361 741 03/11/2017, 17:39 03/11/2017, 16:58 192 48000 MPEG audio file 5 08/03/2018, 10:58
10 Traccia 10 10128290 421 03/11/2017, 17:39 03/11/2017, 16:58 192 48000 MPEG audio file 1 03/11/2017, 16:58
When I use this code to read it, the program hangs. (The i holds the number of lines in the file). The hex dumps which follow seem to show the export from iTunes is in 16bit characters.
The complete code for reading the text file is
file_name="full path to file goes here"
f = open(file_name, "r")
i=227
for x in range(0, i):
line = f.readline()
When I read the code into text wrangler, selected all the text, and pasted it into a new document. The code worked fine.
A text dump of part of the original file looks like this to start with the new file following
00000000: FF FE 4E 00 61 00 6D 00 65 00 09 00 41 00 72 00 ..N.a.m.e...A.r.
00000010: 74 00 69 00 73 00 74 00 09 00 43 00 6F 00 6D 00 t.i.s.t...C.o.m.
00000020: 70 00 6F 00 73 00 65 00 72 00 09 00 41 00 6C 00 p.o.s.e.r...A.l.
00000030: 62 00 75 00 6D 00 09 00 47 00 72 00 6F 00 75 00 b.u.m...G.r.o.u.
00000040: 70 00 69 00 6E 00 67 00 09 00 57 00 6F 00 72 00 p.i.n.g...W.o.r.
00000050: 6B 00 09 00 4D 00 6F 00 76 00 65 00 6D 00 65 00 k...M.o.v.e.m.e.
00000060: 6E 00 74 00 20 00 4E 00 75 00 6D 00 62 00 65 00 n.t. .N.u.m.b.e.
00000070: 72 00 09 00 4D 00 6F 00 76 00 65 00 6D 00 65 00 r...M.o.v.e.m.e.
00000080: 6E 00 74 00 20 00 43 00 6F 00 75 00 6E 00 74 00 n.t. .C.o.u.n.t.
00000090: 09 00 4D 00 6F 00 76 00 65 00 6D 00 65 00 6E 00 ..M.o.v.e.m.e.n.
000000A0: 74 00 20 00 4E 00 61 00 6D 00 65 00 09 00 47 00 t. .N.a.m.e...G.
000000B0: 65 00 6E 00 72 00 65 00 09 00 53 00 69 00 7A 00 e.n.r.e...S.i.z.
000000C0: 65 00 09 00 54 00 69 00 6D 00 65 00 09 00 44 00 e...T.i.m.e...D.
000000D0: 69 00 73 00 63 00 20 00 4E 00 75 00 6D 00 62 00 i.s.c. .N.u.m.b.
000000E0: 65 00 72 00 09 00 44 00 69 00 73 00 63 00 20 00 e.r...D.i.s.c. .
000000F0: 43 00 6F 00 75 00 6E 00 74 00 09 00 54 00 72 00 C.o.u.n.t...T.r.
New file
0000: 4E 61 6D 65 09 41 72 74 69 73 74 09 43 6F 6D 70 Name.Artist.Comp
0010: 6F 73 65 72 09 41 6C 62 75 6D 09 47 72 6F 75 70 oser.Album.Group
0020: 69 6E 67 09 57 6F 72 6B 09 4D 6F 76 65 6D 65 6E ing.Work.Movemen
0030: 74 20 4E 75 6D 62 65 72 09 4D 6F 76 65 6D 65 6E t Number.Movemen
0040: 74 20 43 6F 75 6E 74 09 4D 6F 76 65 6D 65 6E 74 t Count.Movement
0050: 20 4E 61 6D 65 09 47 65 6E 72 65 09 53 69 7A 65 Name.Genre.Size
Your file beginning looks like UTF-16 - see Byte order marks - Wikipedia
Use
file_name="full path to file goes here"
with io.open(file_name,'r', encoding='utf-16-le') as f:
for line in f:
# do something with line
when opening it.
There is no need to use range() or readlines() when reading line by line. If you really need the line-numbers use:
for lineNr,line in enumerate(f):
I would like to know to recover deleted file from FAT. I created fat.img as below.
cd /tmp
dd if=/dev/zero of=fat.img bs=1024 count=100
mkfs.msdos fat.img
mkdir -p /tmp/fs
sudo mount -t msdos fat.img /tmp/fs -o umask=000,loop
Now i am creating file with some text.
cd/tmp/fs
echo "hello world"> name
Using hexdump to see how it was saved
cd ..
hexdump -C fat.img
00000000 eb 3c 90 6d 6b 66 73 2e 66 61 74 00 02 04 01 00 |.<.mkfs.fat.....|
00000010 02 00 02 c8 00 f8 01 00 20 00 40 00 00 00 00 00 |........ .#.....|
00000020 00 00 00 00 80 01 29 3c 69 e6 fb 4e 4f 20 4e 41 |......)<i..NO NA|
00000030 4d 45 20 20 20 20 46 41 54 31 32 20 20 20 0e 1f |ME FAT12 ..|
00000040 be 5b 7c ac 22 c0 74 0b 56 b4 0e bb 07 00 cd 10 |.[|.".t.V.......|
00000050 5e eb f0 32 e4 cd 16 cd 19 eb fe 54 68 69 73 20 |^..2.......This |
00000060 69 73 20 6e 6f 74 20 61 20 62 6f 6f 74 61 62 6c |is not a bootabl|
00000070 65 20 64 69 73 6b 2e 20 20 50 6c 65 61 73 65 20 |e disk. Please |
00000080 69 6e 73 65 72 74 20 61 20 62 6f 6f 74 61 62 6c |insert a bootabl|
00000090 65 20 66 6c 6f 70 70 79 20 61 6e 64 0d 0a 70 72 |e floppy and..pr|
000000a0 65 73 73 20 61 6e 79 20 6b 65 79 20 74 6f 20 74 |ess any key to t|
000000b0 72 79 20 61 67 61 69 6e 20 2e 2e 2e 20 0d 0a 00 |ry again ... ...|
000000c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.|
00000200 f8 ff ff 00 f0 ff 00 00 00 00 00 00 00 00 00 00 |................|
00000210 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000400 f8 ff ff 00 f0 ff 00 00 00 00 00 00 00 00 00 00 |................|
00000410 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000600 4e 41 4d 45 20 20 20 20 20 20 20 20 00 00 00 00 |NAME ....|
00000610 00 00 00 00 00 00 21 86 91 4b 03 00 0c 00 00 00 |......!..K......|
00000620 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00004e00 68 65 6c 6c 6f 20 77 6f 72 6c 64 0a 00 00 00 00 |hello world.....|
00004e10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00019000
After deleting file name we can see change in hexdump
00000600 4e 41 4d 45 20 20 20 20 20 20 20 20 00 00 00 00 |.AME ....|
00000610 00 00 00 00 00 00 21 86 91 4b 03 00 0c 00 00 00 |......!..K......|
00000620 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
And here is my question do you have any suggestion how can i change fat.img to .AME to NAME to recovery my file?
how can i change fat.img to .AME to NAME to recovery my file?
The short answer is with dd, an example with the necessary caveats follows below.
Adding to Martin's answer, while manipulating the bytes to restore the file within the floppy image is a relatively straight-forward proposition with dd, computing where and what within the file allocation table(s) needs to be restored is the challenge. Walking through the use of dd to restore the file itself, knowing what bytes need attention is illustrated by the following example.
Creating a floppy image to work with saves you from having to experiment on your actual image. Simply duplicate your image you wish to work with, or create a new one within a file on your hard drive. You can do that easily with mkfs.msdos (adjust the filesystem type as needed), and then mount the file within your filesystem as follows, e.g.
$ mkfs.msdos -C /home/david/tmp/tt/floppy_144.img 1440
$ sudo mount /home/david/tmp/tt/floppy_144.img /mnt/fd
Now let's add the NAME file:
$ echo "hello world" > NAME
$ sudo cp -a NAME /mnt/fd
$ ls -l /mnt/fd
total 1
-rwxr-xr-x 1 root root 12 Dec 17 13:55 NAME
$ cat /mnt/fd/NAME
hello world
Before deleting the file from your image, hexdump the contents so you can see exactly what needs to be restored. (this is what you must compute in order to know where and what to restore with your original image, you will need to consult a reference for the precise filesystem at issue)
$ hexdump -C floppy_144.img >flpwname.txt
Now delete the file from your image and again save a hexdump showing the changes.
$ sudo rm /mnt/fd/NAME
$ hexdump -C floppy_144.img >flpwoname.txt
Now you can examing the difference with diff. What you find is you must restore more than the first name of the file that was deleted, you will need to restore the file allocation table entries so that the restored file can again be located within the filesystem (both copies of the FAT), e.g.
$ diff flpwname.txt flpwoname.txt
16c16
< 00000200 f0 ff ff 00 f0 ff 00 00 00 00 00 00 00 00 00 00 |................|
---
> 00000200 f0 ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
19c19
< 00001400 f0 ff ff 00 f0 ff 00 00 00 00 00 00 00 00 00 00 |................|
---
> 00001400 f0 ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
22c22
< 00002600 4e 41 4d 45 20 20 20 20 20 20 20 20 00 00 fa 9e |NAME ....|
---
> 00002600 e5 41 4d 45 20 20 20 20 20 20 20 20 00 00 fa 9e |.AME ....|
Note above the entries for the file allocation table(s) at 0x204 and 0x1404 were zeroed when the file was removed. Restoring the bytes to the original can be easily done with dd but pay attention to your options. Specifically your block size (bs), output block size (obs), count and seek must all be in bytes (specified by appending c) to the number and you must set the notrunc conversion option to prevent truncating your image following the changes you make. Lastly, all sizes must be specified in decimal not hexadecimal.
Further, if you are using bash, you can use a process redirection to specify the bytes to replace (e.g. if=<(printf "\xf0\xff") to write the hex bytes f0 and ff), otherwise, you will have to prepare input files containing your replacement strings. The dd commands to restore the FAT and the first character of the filename are fairly simple (consult man 1 dd for option explanation).
Below we restore the first copy of the FAT, then the second, and finally restore the first character of the filename. The seek (offset) values are just those provided by hexdump converted to decimal. (you should unmount your filesystem before making changes. you can make changes while your floppy image is mounted, but they won't be reflected until you remount)
$ sudo umount /mnt/fd
$ dd if=<(printf "\xf0\xff") of=floppy_144.img \
bs=1c obs=1c count=2c seek=516c conv=notrunc
$ dd if=<(printf "\xf0\xff") of=floppy_144.img \
bs=1c obs=1c count=2c seek=5124c conv=notrunc
$ dd if=<(printf "N") of=floppy_144.img \
bs=1c obs=1c count=1c seek=9728c conv=notrunc
Now you can create a hexdump of the repaired floppy image and compare that to the original. If all has gone as it should, there will be no difference.
$ hexdump -C floppy_144.img >flprepair.txt
$ diff flpwname.txt flprepair.txt
Finally, just remount your filesystem and confirm the file has been restored.
$ sudo mount /home/david/tmp/tt/floppy_144.img /mnt/fd
$ ls -l /mnt/fd
total 1
-rwxr-xr-x 1 root root 12 Dec 17 13:55 NAME
$ cat /mnt/fd/NAME
hello world
That's it. I hope this is what you were looking for. There are a number of tools that automate this process for you, but dd and a pencil and paper can get you by.
The full hexdumps follow for completeness:
Original/Restored
$ cat flpwname.txt
00000000 eb 3c 90 6d 6b 66 73 2e 66 61 74 00 02 01 01 00 |.<.mkfs.fat.....|
00000010 02 e0 00 40 0b f0 09 00 12 00 02 00 00 00 00 00 |...#............|
00000020 00 00 00 00 00 01 29 2c 72 18 ba 4e 4f 20 4e 41 |......),r..NO NA|
00000030 4d 45 20 20 20 20 46 41 54 31 32 20 20 20 0e 1f |ME FAT12 ..|
00000040 be 5b 7c ac 22 c0 74 0b 56 b4 0e bb 07 00 cd 10 |.[|.".t.V.......|
00000050 5e eb f0 32 e4 cd 16 cd 19 eb fe 54 68 69 73 20 |^..2.......This |
00000060 69 73 20 6e 6f 74 20 61 20 62 6f 6f 74 61 62 6c |is not a bootabl|
00000070 65 20 64 69 73 6b 2e 20 20 50 6c 65 61 73 65 20 |e disk. Please |
00000080 69 6e 73 65 72 74 20 61 20 62 6f 6f 74 61 62 6c |insert a bootabl|
00000090 65 20 66 6c 6f 70 70 79 20 61 6e 64 0d 0a 70 72 |e floppy and..pr|
000000a0 65 73 73 20 61 6e 79 20 6b 65 79 20 74 6f 20 74 |ess any key to t|
000000b0 72 79 20 61 67 61 69 6e 20 2e 2e 2e 20 0d 0a 00 |ry again ... ...|
000000c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.|
00000200 f0 ff ff 00 f0 ff 00 00 00 00 00 00 00 00 00 00 |................|
00000210 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00001400 f0 ff ff 00 f0 ff 00 00 00 00 00 00 00 00 00 00 |................|
00001410 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00002600 4e 41 4d 45 20 20 20 20 20 20 20 20 00 00 fa 9e |NAME ....|
00002610 91 4b 91 4b 00 00 f5 9e 91 4b 03 00 0c 00 00 00 |.K.K.....K......|
00002620 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00004400 68 65 6c 6c 6f 20 77 6f 72 6c 64 0a 00 00 00 00 |hello world.....|
00004410 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00168000
After NAME Deletion
$ cat flpwoname.txt
00000000 eb 3c 90 6d 6b 66 73 2e 66 61 74 00 02 01 01 00 |.<.mkfs.fat.....|
00000010 02 e0 00 40 0b f0 09 00 12 00 02 00 00 00 00 00 |...#............|
00000020 00 00 00 00 00 01 29 2c 72 18 ba 4e 4f 20 4e 41 |......),r..NO NA|
00000030 4d 45 20 20 20 20 46 41 54 31 32 20 20 20 0e 1f |ME FAT12 ..|
00000040 be 5b 7c ac 22 c0 74 0b 56 b4 0e bb 07 00 cd 10 |.[|.".t.V.......|
00000050 5e eb f0 32 e4 cd 16 cd 19 eb fe 54 68 69 73 20 |^..2.......This |
00000060 69 73 20 6e 6f 74 20 61 20 62 6f 6f 74 61 62 6c |is not a bootabl|
00000070 65 20 64 69 73 6b 2e 20 20 50 6c 65 61 73 65 20 |e disk. Please |
00000080 69 6e 73 65 72 74 20 61 20 62 6f 6f 74 61 62 6c |insert a bootabl|
00000090 65 20 66 6c 6f 70 70 79 20 61 6e 64 0d 0a 70 72 |e floppy and..pr|
000000a0 65 73 73 20 61 6e 79 20 6b 65 79 20 74 6f 20 74 |ess any key to t|
000000b0 72 79 20 61 67 61 69 6e 20 2e 2e 2e 20 0d 0a 00 |ry again ... ...|
000000c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.|
00000200 f0 ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000210 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00001400 f0 ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00001410 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00002600 e5 41 4d 45 20 20 20 20 20 20 20 20 00 00 fa 9e |.AME ....|
00002610 91 4b 91 4b 00 00 f5 9e 91 4b 03 00 0c 00 00 00 |.K.K.....K......|
00002620 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00004400 68 65 6c 6c 6f 20 77 6f 72 6c 64 0a 00 00 00 00 |hello world.....|
00004410 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00168000
I'm developing a BitTorrent client and I'm having trouble getting answers to my piece requests.
To debug, I followed a conversation between uTorrent and transmission using Wireshark and tried to imitate same conversation in my client. But it still doesn't work.
Below is an example conversation happening between my client and transmission. (my client also using -TR--- prefixed peer id, this is only for testing purposes and I'll change this)
Indented messages are coming from transmission, others are messages my client send.
Note that this conversation is not exactly same as how uTorrent and transmission would talk, because my client does not support fast extension yet. (BEP 6)
(Output is taken from Wireshark, lines starting with -- are my comments)
00000000 13 42 69 74 54 6f 72 72 65 6e 74 20 70 72 6f 74 .BitTorr ent prot
00000010 6f 63 6f 6c 00 00 00 00 00 10 00 00 f8 9e 0d fd ocol.... ........
00000020 9c fc a8 52 d9 7a d6 af a4 4d 8f 73 ce 70 b6 36 ...R.z.. .M.s.p.6
00000030 2d 54 52 32 38 34 30 2d 36 68 61 67 76 30 73 70 -TR2840- 6hagv0sp
00000040 34 67 37 6b 4g7k
-- ^ my handshake to transmission
00000000 13 42 69 74 54 6f 72 72 65 6e 74 20 70 72 6f 74 .BitTorr ent prot
00000010 6f 63 6f 6c 00 00 00 00 00 10 00 04 f8 9e 0d fd ocol.... ........
00000020 9c fc a8 52 d9 7a d6 af a4 4d 8f 73 ce 70 b6 36 ...R.z.. .M.s.p.6
00000030 2d 54 52 32 38 34 30 2d 72 73 35 68 71 67 32 68 -TR2840- rs5hqg2h
00000040 6e 70 68 64 nphd
-- ^ transmission answers to my handshake
00000044 00 00 00 1a 14 00 64 31 3a 6d 64 31 31 3a 75 74 ......d1 :md11:ut
00000054 5f 6d 65 74 61 64 61 74 61 69 33 65 65 65 _metadat ai3eee
-- ^ my extended handshake to transmission
00000044 00 00 00 72 14 00 64 31 3a 65 69 31 65 31 3a 6d ...r..d1 :ei1e1:m
00000054 64 31 31 3a 75 74 5f 6d 65 74 61 64 61 74 61 69 d11:ut_m etadatai
00000064 33 65 65 31 33 3a 6d 65 74 61 64 61 74 61 5f 73 3ee13:me tadata_s
00000074 69 7a 65 69 31 34 37 65 31 3a 70 69 35 31 34 31 izei147e 1:pi5141
00000084 33 65 34 3a 72 65 71 71 69 35 31 32 65 31 31 3a 3e4:reqq i512e11:
00000094 75 70 6c 6f 61 64 5f 6f 6e 6c 79 69 31 65 31 3a upload_o nlyi1e1:
000000A4 76 31 37 3a 54 72 61 6e 73 6d 69 73 73 69 6f 6e v17:Tran smission
000000B4 20 32 2e 38 34 65 00 00 00 02 05 80 2.84e.. ....
-- ^ transmission's extended handshake and bitfield
000000C0 00 00 00 01 01 .....
-- ^ transmission unchokes me
00000062 00 00 00 01 02 .....
-- ^ my interested message
00000067 00 00 00 0d 06 00 00 00 00 00 00 00 00 00 00 40 ........ .......#
00000077 00 .
-- ^ piece request
-- no answers ...
00000078 00 00 00 0d 06 00 00 00 00 00 00 00 00 00 00 40 ........ .......#
00000088 00 .
-- ^ piece request again, with 10 seconds interval
-- again no answers...
00000089 00 00 00 0d 06 00 00 00 00 00 00 00 00 00 00 40 ........ .......#
00000099 00 .
-- ^ piece request again, with 10 seconds interval
-- no answers...
Any ideas what am I doing wrong?
Thanks.
EDIT: I updated my client to send unchoke just after sending interested, but I'm still having same problem...
The problem was that I was requesting a piece bigger than the total size of the torrent.
The torrent I was using has 2 files, in total of 12KB. However the piece size of the torrent is 16KB and I was requesting 16KB piece even though the torrent file has only one piece and it's 12 KB in total.
After requesting 12KB instead of 16KB, the problem was solved.
I'm having trouble with my home made "for fun" nameserver. It's been a couple of months since I updated it so I'm a bit rusty and thought I'd ask here and see if someone else sees what's wrong. I'm getting a FORMERR when asking for a TXT record, and the same problem occur on different domains, so there's probably something wrong in the packet formatting. Anyone?
dig txt ffffff.com #ns1.ffffff.com
;; Got bad packet: FORMERR
1024 bytes
ce bf 84 00 00 01 00 01 00 02 00 00 06 66 66 66 .............fff
66 66 66 03 63 6f 6d 00 00 10 00 01 c0 0c 00 10 fff.com.........
00 01 00 00 02 58 00 13 12 57 65 6c 63 6f 6d 65 .....X...Welcome
20 74 6f 20 66 66 66 66 66 66 66 00 c0 0c 00 02 .to.fffffff.....
00 01 00 00 02 58 00 10 03 6e 73 31 06 66 66 66 .....X...ns1.fff
66 66 66 03 63 6f 6d 00 c0 0c 00 02 00 01 00 00 fff.com.........
02 58 00 10 03 6e 73 32 06 66 66 66 66 66 66 03 .X...ns2.ffffff.
63 6f 6d 00 00 00 00 00 00 00 00 00 00 00 00 00 com.............
In the example above supplied, I added an incorrect 00 (null terminator) at the end of the TXT-string. After removing the null terminator from the TXT records, the txt records now work on my nameserver.