my code:
def ws_receive(message):
text = message.content['text']
request = json.loads(text)
cmd = request['cmd']
results = run(cmd)
print(cmd)
for result in results:
Group(GROUP_NAME).send({'text':result.decode('utf-8')})
print(result)
cmd is like ping -c 4 www.google.com;
the terminal results is:
[2017/09/24 07:24:44] WebSocket HANDSHAKING / [127.0.0.1:59285]
[2017/09/24 07:24:44] WebSocket CONNECT / [127.0.0.1:59285]
[2017/09/24 07:24:44] HTTP GET /api/hosts/?status=used 200 [0.07, 127.0.0.1:59247]
ping -c 4 www.google.com
2017-09-24 07:24:58.512885 b'PING www.google.com (74.125.23.103): 56 data bytes\n'
2017-09-24 07:24:58.513127 b'64 bytes from 74.125.23.103: icmp_seq=0 ttl=45 time=138.542 ms\n'
2017-09-24 07:24:59.517881 b'64 bytes from 74.125.23.103: icmp_seq=1 ttl=45 time=142.954 ms\n'
2017-09-24 07:25:00.522698 b'64 bytes from 74.125.23.103: icmp_seq=2 ttl=45 time=144.568 ms\n'
2017-09-24 07:25:01.562285 b'64 bytes from 74.125.23.103: icmp_seq=3 ttl=45 time=180.163 ms\n'
2017-09-24 07:25:01.562400 b'\n'
2017-09-24 07:25:01.562459 b'--- www.google.com ping statistics ---\n'
2017-09-24 07:25:01.562517 b'4 packets transmitted, 4 packets received, 0.0% packet loss\n'
2017-09-24 07:25:01.562586 b'round-trip min/avg/max/stddev = 138.542/151.557/180.163/16.662 ms\n'
but,The browser's websocket debugging information is:
so, I‘am sure the channels is execute the command until the end sent the message,but i want real-time send the message.
Try sending immediately:
Group(GROUP_NAME).send({'text':result.decode('utf-8')}, immediately=True)
The reason behind this is that you are inside the websocket consumer function. While you are inside it, the Group.send calls are not executed, but only collected and executed in batch once you leave the function. Using immediately=True overrides this behaviour.
Related
I'm trying to call Google Assistant API using Protocol Buffers (protobuf) over HTTP. refer to:
https://googleapis.github.io/HowToRPC#grpc-fallback-experimental
My problem is that I frequently get HTTP error code 502 when sending request to the back-end service.
To test the problem, I wrote a python script to send (through HTTP POST) the pre-built protobuf binaries and check the response. The test results are:
32KB audio data (about 1 second length of audio), 20 times post, 0 times 502 error received / 32KB 20/0, failure rate: 0%
2*32KB, 20/0, failure rate: 0%
3*32KB, 20/3, failure rate: 15%
4*32KB, 20/10, failure rate: 50%
6*32KB, 20/19, failure rate: 95%
HTTP status code is 200 for successful requests, while 502 for failed cases.
where we can see, the larger audio length the greater failure rate.
The python code to post pre-built protobuf binaries is as below. while the content of file f1 is the just protobuf binaries.
def postData():
url = "https://embeddedassistant.googleapis.com/$rpc/google.assistant.embedded.v1alpha2.EmbeddedAssistant/Assist"
header = {"Content-type".encode('utf-8'): "application/x-protobuf".encode('utf-8'),"Accept".encode('utf-8'):"text/plain".encode('utf-8'), "Connection".encode('utf-8'):"keep-alive".encode('utf-8'), "Authorization".encode('utf-8'):repToken.encode('utf-8')}
with open(fl) as f:
r = requests.post(url, data=f, headers=header)
with open(fl + "_out", 'wb') as fd:
print(r.status_code)
fd.write(r.content)
f.close()
fd.close()
I also tried to post binary files which contain invalid protobuf, e.g a mp3 file,
and in this case, no matter the size of the file, the HTTP status code returned is always 400 with following message, which is just expected.
Invalid PROTO payload received. Invalid request data in stream body, unexpected message type: 7a
It seems the back-end service sets some kind of limitation for the latency of data transfer which makes it doesn’t work well with low bandwidth connections?
We have a Grandstream UCM6204 PBX connecting to a registered SIP elastic trunk through Twilio. Our trunk originating calls drop after about 60 seconds. Twilio is blaming Grandstream but Grandstream is blaming Twilio. Each is saying the other is not properly formatting or not reading the packet correctly. Pcap log with single 200 ACK packet in question exported.
According to Twilio, the packet should have an acknowledge something like this:
ACK sip:172.18.23.153:5060 SIP/2.0
Grandstream says they (their unit) won't send it to the private IP address and should be sent to the record-route IP address where it will be forwarded to the private IP based on header info. I'm too much of a newbie here to know what's right and what's wrong so any suggestions would be great.
No. Time Source Destination Protocol Length Info
3 0.119432 96.10.11.12 54.172.60.2 SIP/SDP 1217 Status: 200 OK |
Frame 3: 1217 bytes on wire (9736 bits), 1217 bytes captured (9736 bits)
Encapsulation type: Linux cooked-mode capture (25)
Arrival Time: Dec 19, 2018 13:51:32.749232000 Eastern Standard Time
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1545245492.749232000 seconds
[Time delta from previous captured frame: 0.050481000 seconds]
[Time delta from previous displayed frame: 0.050481000 seconds]
[Time since reference or first frame: 0.119432000 seconds]
Frame Number: 3
Frame Length: 1217 bytes (9736 bits)
Capture Length: 1217 bytes (9736 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: sll:ethertype:ip:udp:sip:sdp]
[Coloring Rule Name: UDP]
[Coloring Rule String: udp]
Linux cooked capture
Packet type: Unicast to us (0)
Link-layer address type: 1
Link-layer address length: 6
Source: 0e:d7:c3:5c:55:24 (0e:d7:c3:5c:55:24)
Unused: 0000
Protocol: IPv4 (0x0800)
Internet Protocol Version 4, Src: 96.10.11.12, Dst: 54.172.60.2
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
0000 00.. = Differentiated Services Codepoint: Default (0)
.... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
Total Length: 1201
Identification: 0x0000 (0)
Flags: 0x4000, Don't fragment
0... .... .... .... = Reserved bit: Not set
.1.. .... .... .... = Don't fragment: Set
..0. .... .... .... = More fragments: Not set
...0 0000 0000 0000 = Fragment offset: 0
Time to live: 39
Protocol: UDP (17)
Header checksum: 0x3257 [validation disabled]
[Header checksum status: Unverified]
Source: 96.10.11.12
Destination: 54.172.60.2
User Datagram Protocol, Src Port: 5060, Dst Port: 5060
Source Port: 5060
Destination Port: 5060
Length: 1181
Checksum: 0xfa57 [unverified]
[Checksum Status: Unverified]
[Stream index: 0]
Session Initiation Protocol (200)
Status-Line: SIP/2.0 200 OK
Status-Code: 200
[Resent Packet: False]
[Request Frame: 1]
[Response Time (ms): 119]
Message Header
Via: SIP/2.0/UDP 54.172.60.2:5060;rport=5060;received=54.172.60.2;branch=z9hG4bK0d03.870e90c7.0
Transport: UDP
Sent-by Address: 54.172.60.2
Sent-by port: 5060
RPort: 5060
Received: 54.172.60.2
Branch: z9hG4bK0d03.870e90c7.0
Via: SIP/2.0/UDP 172.18.15.132:5060;rport=5060;received=172.18.15.132;branch=z9hG4bK5d21b0af-3104-4e32-96a7-7e89edd39a93_6772d868_310-9499633517006747707
Transport: UDP
Sent-by Address: 172.18.15.132
Sent-by port: 5060
RPort: 5060
Received: 172.18.15.132
Branch: z9hG4bK5d21b0af-3104-4e32-96a7-7e89edd39a93_6772d868_310-9499633517006747707
Record-Route: <sip:54.172.60.2:5060;lr;ftag=90419967_6772d868_5d21b0af-3104-4e32-96a7-7e89edd39a93>
Record-Route URI: sip:54.172.60.2:5060;lr;ftag=90419967_6772d868_5d21b0af-3104-4e32-96a7-7e89edd39a93
Record-Route Host Part: 54.172.60.2
Record-Route Host Port: 5060
Record-Route URI parameter: lr
Record-Route URI parameter: ftag=90419967_6772d868_5d21b0af-3104-4e32-96a7-7e89edd39a93
Call-ID: 937861cfda42d874af27d391663108b1#0.0.0.0
From: <sip:+12485551212#somebody.pstn.twilio.com>;tag=90419967_6772d868_5d21b0af-3104-4e32-96a7-7e89edd39a93
SIP from address: sip:+12485551212#somebody.pstn.twilio.com
SIP from address User Part: +12485551212
E.164 number (MSISDN): 12485551212
Country Code: Americas (1)
SIP from address Host Part: somebody.pstn.twilio.com
SIP from tag: 90419967_6772d868_5d21b0af-3104-4e32-96a7-7e89edd39a93
To: <sip:+12486661212#96.10.11.12>;tag=68625bc3-5cb5-4bd4-a255-ce12744a3514
SIP to address: sip:+12486661212#96.10.11.12
SIP to address User Part: +12486661212
E.164 number (MSISDN): 12486661212
Country Code: Americas (1)
SIP to address Host Part: 96.10.11.12
SIP to tag: 68625bc3-5cb5-4bd4-a255-ce12744a3514
CSeq: 28344 INVITE
Sequence Number: 28344
Method: INVITE
Server: Grandstream UCM6204V1.5A 1.0.18.12
Contact: <sip:+12485551212#192.168.4.10:5060>
Contact URI: sip:+12485551212#192.168.4.10:5060
Contact URI User Part: +12485551212
E.164 number (MSISDN): 12485551212
Country Code: Americas (1)
Contact URI Host Part: 192.168.4.10
Contact URI Host Port: 5060
Allow: OPTIONS, INFO, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REFER, MESSAGE, REGISTER
Supported: 100rel, timer, replaces, norefersub
Content-Type: application/sdp
Content-Length: 237
Message Body
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): - 1796373137 1796373139 IN IP4 192.168.4.10
Owner Username: -
Session ID: 1796373137
Session Version: 1796373139
Owner Network Type: IN
Owner Address Type: IP4
Owner Address: 192.168.4.10
Session Name (s): Asterisk
Connection Information (c): IN IP4 192.168.4.10
Connection Network Type: IN
Connection Address Type: IP4
Connection Address: 192.168.4.10
Time Description, active time (t): 0 0
Session Start Time: 0
Session Stop Time: 0
Media Description, name and address (m): audio 13894 RTP/AVP 0 101
Media Type: audio
Media Port: 13894
Media Protocol: RTP/AVP
Media Format: ITU-T G.711 PCMU
Media Format: DynamicRTP-Type-101
Media Attribute (a): rtpmap:0 PCMU/8000
Media Attribute Fieldname: rtpmap
Media Format: 0
MIME Type: PCMU
Sample Rate: 8000
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute Fieldname: rtpmap
Media Format: 101
MIME Type: telephone-event
Sample Rate: 8000
Media Attribute (a): fmtp:101 0-16
Media Attribute Fieldname: fmtp
Media Format: 101 [telephone-event]
Media format specific parameters: 0-16
Media Attribute (a): ptime:20
Media Attribute Fieldname: ptime
Media Attribute Value: 20
Media Attribute (a): maxptime:150
Media Attribute Fieldname: maxptime
Media Attribute Value: 150
Media Attribute (a): sendrecv
I'm trying to serve a video file as response when certain request hits the server (server running on a mobile app). eg: someone goes to http://mylocalip:8080/video, and I want to serve him with a video.
This video file can be stored locally, or can be external. I started trying to serve a file located on a SMB server, so I tried using this code to get the file from the server and returning it (I know it's waiting for the whole file to read instead of reading and sending chunks, but should work right?):
webServer.addDefaultHandlerForMethod("GET", requestClass: GCDWebServerRequest.self, processBlock: {request in
print("########\n########Request: \(request)")
let webrequested:GCDWebServerRequest = request;
let urlcita:String = String(webrequested.URL)
print("URL of requests\(urlcita)")
if urlcita.rangeOfString("videosmb") != nil{
print("It's a video SMB request")
//Test fake SMB file predefined. Read File using KxSMB
let route:String = "smb://192.168.1.205/ServidorAH/video.avi";
let extensFile:NSString = (route as NSString).pathExtension
let contentype = GCDWebServerGetMimeTypeForExtension(extensFile as String);
print("Content type MIME \(contentype)")
//Open SMB file using KxSMB
let authcredentials = KxSMBAuth.smbAuthWorkgroup("", username: "Guest", password: "");
let provider = KxSMBProvider.sharedSmbProvider()!
let archivoes = provider.fetchAtPath(route, auth: authcredentials)
//Switch to manually end the reading when switched to true. In the future will send chunks of data until the end, instead of reading the whole file first.
var interruptor:Bool = false
//Response Stream block
let responseStream: GCDWebServerStreamedResponse = GCDWebServerStreamedResponse(contentType: contentype, asyncStreamBlock: { completionBlock in
if (interruptor == true)
{
print("Test: End of reading")
completionBlock(NSData(), nil);
}
if archivoes!.isKindOfClass(NSError){
//It can not find the file, SMB error, so empty NSDATA to completion block
let errorcito:NSError = archivoes as! NSError
print("Error obteniendo archivo SMB: \(errorcito.localizedDescription)");
completionBlock(NSData(), nil);
}else{
print("Archivo SMB adecuado \(archivoes)")
let datos:NSData = archivoes!.readDataToEndOfFile()
//Print lenght of data (to check the size of the file)
print("Data lenght \(datos.length)")
//Set switch to true, so the next call will send an empty daya completion block
interruptor = true
//Send data chunk (in this case everything)
completionBlock(datos, nil);
}
})
return responseStream
}else{
//Default response
return GCDWebServerDataResponse(HTML:"<html><body><p>Hello World<br></p></body></html>")
}
However, I can't make it work. I always get a broken pipe error, and the web player accessing the web server (browsing from the mac and iOS too) doesn't play anything. I've also tried using an embeded iOS player to log the response (KxMovie). I get something like this:
[DEBUG] Did open connection on socket 19
[DEBUG] Connection received 177 bytes on socket 19
[DEBUG] Connection on socket 19 preflighting request "GET /videosmb" with 177 bytes body
[DEBUG] Connection on socket 19 processing request "GET /videosmb" with 177 bytes body
[DEBUG] Did connect
[DEBUG] Did start background task
[DEBUG] Connection sent 175 bytes on socket 19
...
Using a local player (KxMovie) from inside the App, here appears to be reading the file headers and it gets the right file size and dimensions of the video. However it doesn't play and it ends saying it reached the end of the video (without playing it). Just after that, WebServer shows an error:
...
[ERROR] Error while writing to socket 19: Broken pipe (32)
[DEBUG] Did close connection on socket 19
[VERBOSE] [fe80::cd0:28cd:3a37:b871%en1:8080] fe80::cd0:28cd:3a37:b871%en1:50109 200 "GET /videosmb" (177 | 175)
[DEBUG] Did disconnect
[DEBUG] Did end background task
Given the fact this is the first time I'm dealing with SMB servers, I though that maybe I was doing something wrong with the SMB part, so I decided to go for a simplified method just for testing.
This time I tried to serve a simple mp4 file stored on a remote webserver (not SMB). It didn't work either.
Finally I tried to serve a local file included in the main Bundle of the App, and the same happened: nothing. Here is the code:
webServer.addDefaultHandlerForMethod("GET", requestClass: GCDWebServerRequest.self, processBlock: {request in
print("########\n########Request: \(request)")
let webrequested:GCDWebServerRequest = request;
let url:String = String(webrequested.URL)
print("URL of request: \(url)")
if url.rangeOfString("video") != nil{
print("It's a video request")
let rutalocalita = (NSBundle.mainBundle()).pathForResource("video", ofType: "avi")
let datos = NSData(contentsOfFile: rutalocalita!)!
print("video size: \(datos.length)")
return GCDWebServerDataResponse(data: datos, contentType: "video/avi")
}else{
//Default Response: Simple web
return GCDWebServerDataResponse(HTML:"<html><body><p>Hello World<br></p></body></html>")
}
})
This is what the log looks like:
[DEBUG] Did open connection on socket 19
[DEBUG] Connection received 177 bytes on socket 19
[DEBUG] Connection on socket 19 preflighting request "GET /video" with 177 bytes body
[DEBUG] Connection on socket 19 processing request "GET /video" with 177 bytes body
[DEBUG] Did connect
[DEBUG] Did start background task
[myCUSTOMDebug] Read 13584902 b. I'm going to send the response back to the request.
[DEBUG] Connection sent 173 bytes on socket 19
...
Here the local Playing I'm using inside the app to track the response, is able to read things like:
header='HTTP/1.1 200 OK'
2015-10-17 17:51:41.571 videotvtest[262:14252] http_code=200
2015-10-17 17:51:41.571 videotvtest[262:14252] header='Cache-Control: no-cache'
2015-10-17 17:51:41.571 videotvtest[262:14252] header='Content-Length: 13584902'
2015-10-17 17:51:41.572 videotvtest[262:14252] header='Content-Type: video/avi'
2015-10-17 17:51:41.572 videotvtest[262:14252] header='Connection: Close'
2015-10-17 17:51:41.573 videotvtest[262:14252] header='Server: GCDWebServer'
...
[ERROR] Error while writing to socket 19: Broken pipe (32)
[DEBUG] Did close connection on socket 19
[VERBOSE] [fe80::cd0:28cd:3a37:b871%en1:8080] fe80::cd0:28cd:3a37:b871%en1:50155 200 "GET /video" (177 | 173)
netbios_ns_send_name_query, name query sent for '*'.
[DEBUG] Did disconnect
[DEBUG] Did end background task
I'm playing around with tvOS and Xcode 7 for this, but I guess it should be ok if I'm able to show a regular HTML response... so I'm sure I'm missing something, or maybe I missed some framework when installing WebServer (I'm not using pods)?
Thanks in advance
If you want to serve a video file that can play in the browser using the video tag, at least on Chrome and Safari, you need to implement HTTP range requests.
GCDWebServer automatically implement range support if you use GCDWebServerFileResponse. If you use another type of response you would need to implement it yourself based on the byteRange property of the incoming GCDWebServerRequest. You should copy-paste the logic from GCDWebServerFileResponse.m.
I wrote some code on VxWorks to download a file from a TFTP server using tftpLib but the get gives me a timeout:
ERR [TFTP] tftpSend:479: Transfer Timed Out.
ERR [TFTP] tftpGet:1077: File transfer error.
Error has occurred: 4915207
which isn't right as the host is reachable:
ping("3.94.213.53",3)
Pinging 3.94.213.53 (3.94.213.53) with 64 bytes of data:
Reply from 3.94.213.53 bytes=64 ttl=63 seq=0 time<1ms
Reply from 3.94.213.53 bytes=64 ttl=63 seq=1 time<1ms
Reply from 3.94.213.53 bytes=64 ttl=63 seq=2 time<1ms
and when I do this from the Linux shell, it works just as expected:
tftp -r "artifacts/ngfm.bin" -g 3.94.213.53
What might be the problem here?
The get section of my code looks like:
pFile = fopen("flash:/ngfm.bin","wb");
if (pFile != NULL) {
/* Get file from TFTP server and write it to the file descriptor */
if (OK == (status = tftpGet (pTftpDesc, pFilename, pFile, TFTP_CLIENT))) {
printf("tftpGet() successful\n");
} else {
printf("Error has occurred: %d\n", errno); // errno is where the error is stored
}
} else {
printf("Bad file pointer pFile");
}
edit:
The code I have above the get portion is:
/*Initiate TFTP session*/
if ((pTftpDesc = tftpInit ()) == NULL)
printf("Error on tftpInit()\n");
/*connect to TFTP host and set transfer mode*/
if ((tftpPeerSet (pTftpDesc, pHost, port) == ERROR) ||
(tftpModeSet (pTftpDesc, pMode) == ERROR)) {
(void) tftpQuit (pTftpDesc);
printf("Error on tftpPeerSet()\n");
return ERROR;
}
I believe your problem is caused by lack of calling of tftpModeSet - http://www.vxdev.com/docs/vx55man/vxworks/ref/tftpLib.html#tftpModeSet
So add:
tftpModeSet(pTftpDesc, "binary");
This will prevent your binary file from causing the stream to die off on the first \n
Okay, turns out that TFTP is a no go in my situation.
I hooked up Wireshark and saw that my client is getting through to the server just fine on port 69. I previously have also made sure that I have port forwarding on port 69 setup in my iptable rules properly. Now I just read this on Wikipedia:
Data transfer is initiated on port 69, but the data transfer ports are
chosen independently by the sender and receiver during initialization
of the connection. The ports are chosen at random according to the
parameters of the networking stack, typically from the range of
ephemeral ports
i.e. TFTP won't work for me because I need NAT and it has to be secure. I'll need to go with a protocol that's connection orriented, ftp e.g.
I found that the standar VxWorks library also contains ftpLib.h (http://www.vxdev.com/docs/vx55man/vxworks/ref/ftpLib.html#ftpLs) that will hopefully resolve my NAT issues as FTP works with connection based TCP.
I have a GPS tracker . It's a chinese model, with sparse documentation. It's got a built in gps and a gprs module (sim) and it's sending me my data to a particular ip address.
No idea what the format is
I using "template" OpenGTS server
Log:
[INFO_|06/20 11:47:28|TrackClientPacketHandler.sessionStarted:256] Begin TCP communication: 84.15.15.12 [Mon Jun 20 11:47:28 EE ST 2011]
[INFO_|06/20 11:47:37|TrackClientPacketHandler.parseInsertRecord_ASCII_1:565] Parsing: �32472798�?
[WARN_|06/20 11:47:37|TrackClientPacketHandler.parseInsertRecord_ASCII_1:576] Invalid number of fields
[WARN_|06/20 11:47:41|ServerSocketThread$ServerSessionThread.readPacket:2001] Timeout: 0x007F070F00FFFFFFFF00F0640000000000000000000000000000000000000000000000000000000000000000000000000000B822511D1013031E00067360215281F2000000000630079659105100000000000000000000000000000000000000000000000000000000000000000000000000B4
[WARN_|06/20 11:47:41|ServerSocketThread$ServerSessionThread.run:1527] Read timeout [# 115]
[INFO_|06/20 11:47:41|ServerSocketThread$ServerSessionThread.run:1550] End of session ...
[INFO_|06/20 11:47:41|TrackClientPacketHandler.sessionTerminated:270] End TCP communication: 84.15.15.12
�32472798�? is part of IMEI number
Please help to understand data format
It seems that this tracker uses a binary protocol and it will be too hard to implement this protocol without documentation.