I have a program that heavily relies on a usb connection to send and receive packets to a device... This needs to run while the phone is locked. I'm not super familiar with android cycles and I currently have a service running in .net maui. One some devices, the connection will slow down or even stop while the device is locked. This can be resolved by disabling power saving options on the app and phone. Anyone know if there's a correct way to implement this service?
I currently have a working c# service (dependency injection) that allows me to send and receive packets in the background using USB Endpoint.
Related
as the question says, how can I communicate from a rest API to Windows application. I have Windows application that connects to a linux server over TCP connection. This application manages multiple connections (around 7-8k tcp connection on different ports and keeps alive these connections all the time.). I have a mobile application that connects to rest API (APS.net C#) and works as expected. Now i want to send some more information from linux server to mobile client. How can I send a request from rest API to windows application and get response to send it to mobile application when requested from mobile. This communication between API and Windows application should be asynchronous and could handle around 7-8k connections without delay. How can i achieve this? Is it possible to achieve this using current architecture? or should I change it? I am willing to adopt any proposed architecture or new framework and any other programming language which serves the purpose good. Here is rough structure.
I think you can try using SignalR, it allows for dual communication between client and serer
It uses websockets as its underlying connection and you can either send messages to all connected clients or a specific client.
https://dotnet.microsoft.com/apps/aspnet/signalr
I haven't been able to find any resources regarding this, so I thought I'd ask here.
I have an iOS app that I am developing, as well as a C# desktop app. I'm currently able to connect the two by creating a Socket Server on the desktop app, and connecting from the iOS app. This works well, but I'd like to do this without requiring the devices being on the same network. Communicating via Usb (lightning port) seems like the logical choice, but I can't find any resources at all about how to do this. Are there any tools or best practices regarding this, or is this even possible?
Thanks!
Peertalk, an open source library allowing to pass TCP connections through the USB connection without being part of the MFI program. PeerTalk uses the iTunes usbmux system to relay TCP connections across the iOS USB connection.
I wasn't able to use Peertalk, since I'm using Xamarin for my project. However, I spent the last week researching and documenting what I learned, and I posted it as a blog post here
http://thecodewash.blogspot.com/2017/05/communicating-with-your-ios-app-over.html
Hopefully this helps others.
Long story short
I am trying to discover (Android) devices from a Windows 10 computer, using WiFi Direct Services - but it seems to me that Windows and Android do not agree on the standard here.
When I write Wifi Direct Services or Wifi Direct Advertisement, I mean the feature where a WiFi Direct capable devices can broadcast what services it offers, so potential peers can scan for available devices / services before they make any connection.
Have any one had any success with this across the Windows-Android gap?
Details on what I have tried
So I have been working a bit on this, searching for documentation and examples.
Android <-> Android
Using this Service Discovery example for Android, I have had success with making two Android devices find each-other and list their available service(s) before any actual WiFi Direct connection was made.
The way it works is that a device that want to find other devices (services) will broadcast probe requests. A device publishing a service will then see these probe requests and respond with a probe answer. The probe answer include Bonjour(-like) information informing the first device about available services. This is (similar to) active scanning.
Enter Windows 10
I have been playing with the WiFi Direct Services example project (and others) from Microsoft - but without the big success. Windows is able to see the Android device(s) but
only if the Android device is in Service Discovery mode (i.e. sending out probe requests)
Windows is only able to see the device, not which services it provides.
Basically my conclusion (a bit of guessing) is that Windows 10 uses passive scanning and thus (erroneously?) reacts to the probe requests of the Android devices (when Windows should actually send out probe requests itself and react to probe responses).
So, actual question
I am having trouble forming one clear question, sorry, but
Has anybody successfully made a service discovery between Android and Windows?
Does anybody have any insight into how Windows (10) works here? Can I make Windows use the active scanning mode and parse the service announcements?
Other hints that will help on my way is greatly appreciated :-)
Just for some context to anyone finding this question, the Windows API you linked uses a Wi-Fi Alliance standard called Wi-Fi Peer-to-Peer Services (P2Ps) for service discovery in probe requests and responses. A service is advertised and discovered over Probe Response frames when a matching hash is included in a Probe Request frame. The services may also be discovered over ANQP/GAS frames with the type P2Ps.
The Android API uses service discovery as defined in the Wi-Fi Alliance Wi-Fi Peer-to-Peer (P2P) standard. This is a form of service discovery that predates P2Ps. It uses ANQP/GAS frames with the type Bonjour or UPnP.
Both methods are valid and standards based, but they are not compatible with one another. The closest you can (likely) get to compatibility is by using Wi-Fi Direct and no service discovery (you can only see device names essentially at discovery time, rather than a "service").
Windows sample: https://github.com/Microsoft/Windows-universal-samples/tree/master/Samples/WiFiDirect
Android sample: https://developer.android.com/training/connect-devices-wirelessly/wifi-direct.html
I have done this using an Apple Bonjour server running on the Windows side (Bonjour == Apple's implementation of Zero Configuration Networking).
The catch is that I had to use Mono.Zeroconf library to pull it off http://www.mono-project.com/archived/monozeroconf/, and it's a little off the well-trod path because the most popular libraries for this on Windows side are client only and do not allow for registration as a service provider. Also, and as an added surprise, the source in this project hadn't been recompiled recently when I found it. It works though -- I just had to recompile it to get it working with .Net46.
Anyway, the operative point is that Android's Network Service Discovery is interoperable with ZeroConf as they are both DNS-SD based and I've been quite happy with the results after finding out most android devices don't do MultiCasting
I have several machines running an application that plays a video feed from a camera. Each machine is located behind a firewall on different LANs. I am trying to investigate an approach to be able to talk to these machines from an Azure web app and get access to the video they are streaming. I don't want to have to open ports on any LAN. My first attempt at this was to have a client running on each machine that contacts an intermediate Azure service via a TCP port, the port is kept open and the local machine sends data to the Azure service which basically downloads this data and then sends it on to any connected clients.
The problem I am having is the intermediate service essentially has to download each message and then retransmit it to any clients, I don't think this approach will scale as the intermediate server can become overrun very easily. Ideally all I would like the intermediate service to do is manage the connections between the local machines and the end client azure service so that they talk directly to one and other.
I guess this must be similar to what products like TeamViewer or LogMeIn do.
I'd appreciate any pointers or suggestions from others experience.
For my senior design project, we have developed a Windows Store App to control a 2-player tug-of-war style game (all in software) which is controlled by the energy levels of each players EEG signals (specifically alpha/beta bands, relating to concentration levels) which we are transmitting over Bluetooth LE. We are also thinking about controlling a physical component to the game with an STM32F0 Microcontroller.
Basically, every so often (on some event trigger) we want to send a value between -100 and 100 in 2's complement to the uC to control the direction that the motor will move and it's speed. All the research I have done has suggested that Windows Store Apps do not support serial communication at all, but I was hoping there was a not-too-difficult workaround. We have a USB to serial adapter which will be able to communicate with the uC's UART. Is it possible to use something like Tera Term, where the Store app could communicate with the terminal upon some event and send the data over the serial port? Could the Windows App open tera term and write values to it? The communication need only be in one direction.
I'm open to suggestions on alternatives (aside from writing some custom driver, which would be too complicated for the amount of time that we have remaining to finish the project). Should we just completely abandon the prospect of serial communication and look into something like zigbee or bluetooth? I know it's possible to communicate over serial port using System.IO.Ports in a WPF/Windows Forms application but that is not an option at this point, since we have already developed the entirety of the host application (minus this serial comm). Thanks!!
EDIT 1: I'm considering using a UDP socket as a means of sending the necessary data to a background Windows Forms App which should be able to communicate over a serial port.
I don't think that network access to localhost is allowed with store deployed windows store apps. However Bluetooth serial port profile may be a possibility, judging by a quick google revealing this.
However, given that WPF has access to a rich library of IO communications support, and it is mostly a superset of WinRT, a port may be easier than you think.