我正在創建一個應用程序來發送UDP
數據包以便打開LED bulb
。當我連接到由Wifi bridge
創建的Ad-hoc
時,我能夠執行所有操作。無法接收使用GCDAsyncSocket發送的UDP數據包的響應
現在,我想配置Wifi bridge
,以便它可以連接到我的主路由器。我有AT命令集執行此過程,但不知何故,我無法收到我發送給它的命令的響應形式爲Wifi bridge
。
的過程如下: -
步驟1:發送UDP消息發送到LAN廣播 「10.10.100.255」 的IP地址和端口48899 => 「Link_Wi網絡連接」
局域網上的所有Wifi網橋都會響應他們的詳細信息。回答是 「10.10.100.254,ACCF232483E8」步驟2:(可選有關WiFi橋更改設置):然後發送 「+ OK」 的LimitlessLED無線上網的橋樑。發送UDP消息到從步驟1返回的響應IP地址「10.10.100.254」=>「+ ok」
- 步驟3:(可選更改wifi網橋設置):之後,您可以發送AT命令(以\ r \ n結尾)到模塊。
發送UDP數據包的代碼是爲了如下
-(void)configureWifi{
counter++;
NSString *host = @"10.10.100.255";
if ([host length] == 0)
{
[self logError:@"Address required"];
return;
}
int port = 48899; //[portField.text intValue];
if (port <= 0 || port > 65535)
{
[self logError:@"Valid port required"];
return;
}
NSString *msg = @"Link_Wi-Fi";
NSData *data = [msg dataUsingEncoding:NSUTF8StringEncoding];
NSLog(@"the message sent is %@", data);
[udpSocket sendData:data toHost:host port:port withTimeout:-1 tag:tag];
}
我們安裝插座和接收數據,我用這兩個委託方法:
- (void)setupSocket
{
// Setup our socket.
// The socket will invoke our delegate methods using the usual delegate paradigm.
// However, it will invoke the delegate methods on a specified GCD delegate dispatch queue.
//
// Now we can configure the delegate dispatch queues however we want.
// We could simply use the main dispatc queue, so the delegate methods are invoked on the main thread.
// Or we could use a dedicated dispatch queue, which could be helpful if we were doing a lot of processing.
//
// The best approach for your application will depend upon convenience, requirements and performance.
//
// For this simple example, we're just going to use the main thread.
udpSocket = [[GCDAsyncUdpSocket alloc] initWithDelegate:self delegateQueue:dispatch_get_main_queue()];
NSError *error = nil;
if (![udpSocket bindToPort:0 error:&error])
{
[self logError:FORMAT(@"Error binding: %@", error)];
return;
}
if (![udpSocket beginReceiving:&error])
{
[self logError:FORMAT(@"Error receiving: %@", error)];
return;
}
[self logInfo:@"Ready"];
}
並且接收數據這是在發送UDP數據包之後記錄被調用的方法。這是我在項目中使用的GCDAsyncUdpSocket
類的委託方法,用於發送和接收UDP數據包。
- (void)udpSocket:(GCDAsyncUdpSocket *)sock didReceiveData:(NSData *)data
fromAddress:(NSData *)address
withFilterContext:(id)filterContext
{
NSString *msg = [[NSString alloc] initWithData:data encoding:NSUTF8StringEncoding];
if (msg)
{
[self logMessage:FORMAT(@"RECV: %@", msg)];
}
else
{
NSString *host = nil;
uint16_t port = 0;
[GCDAsyncUdpSocket getHost:&host port:&port fromAddress:address];
[self logInfo:FORMAT(@"RECV: Unknown message from: %@:%hu", host, port)];
}
}
一旦我能夠收到響應,我將能夠發送下一個AT命令來配置網橋。
謝謝。任何幫助將不勝感激。
的第一個問題時,有人說,他們正在發送廣播包是我總是問「你怎麼知道這是你的廣播地址?」特別是在10.類A地址空間內。您正在發送至10.10.100.255,但如果您的細分受衆羣中的其他人都認爲它是廣播地址,那麼這只是您的廣播地址。已經編寫了大量設備上的IP堆棧,認爲10.255.255.255是10.x.x.x網絡的廣播地址。您可以發送一個ping到.255地址並觀察儘可能多的響應嗎? – tobinjim
在您的設置方法中,您綁定到端口0,允許操作系統選擇一個空閒端口,然後您開始監聽套接字。你是如何將這個套接字號碼傳達給那些想要聯繫你的應用的人? – tobinjim
@tobinjim我們正在嘗試發送UDP數據包,以「10.10.100.255」或255.255.255.255,以收到多少的Wi-Fi網橋是有效的。一旦我們能夠收到響應,我們就必須將所有UDP數據包發送到「10.10.100.254」或任何我們想要訪問的Wi-Fi網橋。 –