Autor Tema: PIC + Ethernet + Google Cloud Messaging. Una forma de comunicación  (Leído 9556 veces)

0 Usuarios y 1 Visitante están viendo este tema.

Desconectado alperez

  • PIC18
  • ****
  • Mensajes: 255
Hola compañeros. Estoy inmerso en un proyecto de comunicación entre un PIC y una aplicación Android.

Al principio, el PIC enviaba datos al telefono mediante Emails con una cuenta de gmail, necesitando la encriptacion de 512 bits, pero terminando el año 2013 a google se le ocurre ampliar la encriptacion a 1024 bits y ya no me es posible enviar email con una cuenta de gmail (creo que con los pic32 sí que se puede)

Como probablemente todos los proveederores de este servicio vayan incrementando esta seguridad he decidido implementar Google cloud Messaging en mi aplicación.

Este sistema requiere de una activacion (gratuita) de una cuenta de desarrollador en google, activar la API de GCM (Google Cloud Messaging) para obtener una API Key.
Tras este proceso, nuestra aplicación debe registrarse en el servidor de GCM, a continuación recibirá una clave, que posteriormente envio al PIC.
Este pic debe almecenar este RegId para poder enviar mensajes a nuestro Android.

Para enviar mensajes a nuestra aplicación Android, es necesario hacer las peticiones al servidor de google en formato json o texto plano.
Para no complicar las cosas, yo realizo las peticiones en texto plano.
De momento, google no hace obligatorio el uso de ssl en este servidor, es algo opcional así que no hay problemas.

En la aplicación android he implementado un sistema de notificaciones, puesto que el envío de estos mensajes pueden incluir información de cualquier tipo y posteriormente con simple switch case actuar en consecuencia.

Como podeis ver, el límite de esta tecnología lo pone nuestra imaginación.

Si les interesa, mas adelante pondré en este hilo porciones de código para poder implementar esta interesante forma de comunicacion.

Un saludo a todos.


Desconectado MGLSOFT

  • Moderadores
  • DsPIC33
  • *****
  • Mensajes: 7918
Re: PIC + Ethernet + Google Cloud Messaging. Una forma de comunicación
« Respuesta #2 en: 15 de Febrero de 2014, 08:27:28 »
Me interesa mucho !! :-/ :-/
Todos los dias aprendo algo nuevo, el ultimo día de mi vida aprenderé a morir....
Mi Abuelo.

Conectado RedPic

  • Administrador
  • DsPIC33
  • *******
  • Mensajes: 5552
    • Picmania by Redraven
Re: PIC + Ethernet + Google Cloud Messaging. Una forma de comunicación
« Respuesta #3 en: 15 de Febrero de 2014, 15:01:23 »
Hummmm ... escribo para suscribirme. Sigue, alperez, sigue, que te escuchamos  :mrgreen:
Contra la estupidez los propios dioses luchan en vano. Schiller
Mi Güeb : Picmania

Desconectado alperez

  • PIC18
  • ****
  • Mensajes: 255
Re: PIC + Ethernet + Google Cloud Messaging. Una forma de comunicación
« Respuesta #4 en: 15 de Febrero de 2014, 16:36:02 »
Hola de nuevo.

En primer lugar, quiero dar las gracias a aquellas personas que sin otro interés más que el de compartir, me han inspirado o dado la información, para llevar este proyecto adelante.
No me veo capaz de hacer esto si no existiera internet, puesto que TODO, absolutamente TODO, está en la red.

Decirles a todos, que no me veo capaz de resolver todos los problemas que puedan llegar a tener puesto que soy un principiante, pero vamos a intentarlo.

En primer lugar, voy a dar por hecho, que tenemos un PIC "online" con el stack TCP/IP de Microchip y que tenemos la forma de programar un dispositivo android como una tablet o un smartphone.
Yo tengo un PIC24FJ256GB106 con un ENC424J600 conectado a un router y abierto el puerto 9760 como socket para las comunicaciones y lo programo con el IDE MPLAX y XC16 como compilador. Todo en sus ultimas versiones a dia de hoy.
Para programar android tengo Eclipse Juno Version: 4.2.2 y debido a que el plugin ADT está en constante desarrollo no me atrevería a decir que es la última versión.

Si alguien no tiene instalado java, o eclipse o el plugin ADT de google o ninguno de ellos, puede realizar una busqueda en google o ir directamente aquí. Pueden guardar esa página en sus favoritos por que es genial (gracias).

Existe muchísima información sobre java, android y eclipse, sin esa información me hubiera sido imposible realizar este proyecto (aún en desarrollo), yo sólo les citaré algunas fuentes.

Para utlizar GCM debemos activar el servicio con nuestra cuenta gmail en https://code.google.com/apis/console, para generar de una ApiKey.

Esto esta muy bien explicado aquí
Una vez que tenemos esto, tendremos que comenzar a crear nuestro proyecto en eclipse, ojo con la API de google que usamos, ya que debemos usar la api que se adapte a nuestro dispositivo, es decir si vamos a crear una aplicacion para Android 2.2.x (Froyo, API  8 ), no podemos crear nuestra aplicacion con la API 16 (Jelly Bean Android 4.1). Esto podemos verlo aqui:  http://developer.android.com/guide/topics/manifest/uses-sdk-element.html

Es imprescindible que nuestro dispositivo tenga instalado Google Play Services, a continación procedemos a modificar el archivo AndroidManifest.xml de nuestro proyecto, este archivo contiene información de nuestro proyecto, como las clases incluidas, los permisos, la versión y mucho más.

esto es un trozo de mi AndroidManifest

Código: [Seleccionar]
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.socket.rsi_etu"
    android:versionCode="1"
    android:versionName="1.1" >

    <uses-sdk
        android:minSdkVersion="8"
        android:targetSdkVersion="17" />

    <uses-permission android:name="android.permission.INTERNET" />
    <uses-permission android:name="android.permission.ACCESS_WIFI_STATE" />
    <uses-permission android:name="android.permission.GET_ACCOUNTS" />
    <uses-permission android:name="android.permission.WAKE_LOCK" />
    <uses-permission android:name="android.permission.READ_LOGS" />
    <uses-permission android:name="com.google.android.c2dm.permission.RECEIVE" />
    <uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED" />
    <uses-permission android:name="android.permission.VIBRATE" />
    <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />

    <permission
        android:name="com.socket.rsi_etu.android.newgcm.permission.C2D_MESSAGE"
        android:protectionLevel="signature" />

    <uses-permission android:name="com.socket.rsi_etu.android.newgcm.permission.C2D_MESSAGE" />

Les recomiendo que lean esto http://www.sgoliver.net/blog/?p=4126

« Última modificación: 15 de Febrero de 2014, 16:39:15 por alperez »

Desconectado PalitroqueZ

  • Moderadores
  • DsPIC33
  • *****
  • Mensajes: 5490
    • Electrónica Didacta
Re: PIC + Ethernet + Google Cloud Messaging. Una forma de comunicación
« Respuesta #5 en: 15 de Febrero de 2014, 17:03:51 »
y vaya que si está super intersante la información, llegó otro que se sienta en el aula a escuchar la clase  :mrgreen:
La propiedad privada es la mayor garantía de libertad.
Friedrich August von Hayek

Desconectado alperez

  • PIC18
  • ****
  • Mensajes: 255
Re: PIC + Ethernet + Google Cloud Messaging. Una forma de comunicación
« Respuesta #6 en: 15 de Febrero de 2014, 17:06:16 »
Verán mas permisos de los que en principio necesitamos, como VIBRATE, debemos "separar" lo que es GCM (mensajeria) y la notificación PUSH que voy a generar, en la que además hago vibrar mi androide una vez que recibo un mensaje.

Para poder procesar los mensajes recibidos incluimos esto en manifest

Código: [Seleccionar]
       <receiver
            android:name=".GCMBroadcastReceiver"
            android:permission="com.google.android.c2dm.permission.SEND" >
            <intent-filter>
                <action android:name="com.google.android.c2dm.intent.RECEIVE" />
                <category android:name="com.socket.rsi_etu" />
            </intent-filter>
        </receiver>

 la clase llamada por el SO android cuando recibimos un mensaje de nuestro pic es esta:

GCMBroadcastReceiver.java:
Código: [Seleccionar]
import android.app.Activity;
import android.content.ComponentName;
import android.content.Context;
import android.content.Intent;
import android.support.v4.content.WakefulBroadcastReceiver;
import android.util.Log;
public class GCMBroadcastReceiver extends WakefulBroadcastReceiver {
@Override
public void onReceive(Context context, Intent intent) {
Log.d("TAG", "Recibido mensaje");
ComponentName comp = new ComponentName(context.getPackageName(),
GCMIntentService.class.getName());

startWakefulService(context, (intent.setComponent(comp)));

setResultCode(Activity.RESULT_OK);
}
}
como podeis deducir practicamente no hace nada, ya que es similar a una interrupción en nuestro PIC ("haz lo que sea rápido y corre").

Lo que hacemos es llamar a otra clase: GCMIntentService:

Código: [Seleccionar]
public class GCMIntentService extends IntentService {
private static final int NOTIF_ALERTA_ID = 1;

public GCMIntentService() {
super("GCMIntentService");
}

/*
* La clase onHandleIntent es llamada de forma asincrona por Android
* (non-Javadoc)
*
* @see android.app.IntentService#onHandleIntent(android.content.Intent)
*/

@Override
protected void onHandleIntent(Intent intent) {
GoogleCloudMessaging gcm = GoogleCloudMessaging.getInstance(this);

String messageType = gcm.getMessageType(intent);
Bundle extras = intent.getExtras();

if (!extras.isEmpty()) {
String ticker = extras.getString("ticker");
String contentTitle = extras.getString("contentTitle");
String contentText = extras.getString("contentText");
String contentInfo = extras.getString("contentInfo");
String code = extras.getString("contentCode");
if (GoogleCloudMessaging.MESSAGE_TYPE_MESSAGE.equals(messageType)) {
mostrarNotification(ticker, contentTitle, contentText,
contentInfo, code);
}
}
GCMBroadcastReceiver.completeWakefulIntent(intent);
}

private void mostrarNotification(String Ticker, String ContentTitle,
String ContentText, String ContentInfo, String code) {
NotificationManager mNotificationManager = (NotificationManager) getSystemService(Context.NOTIFICATION_SERVICE);
// Sonido por defecto de notificaciones, podemos usar otro
Uri defaultSound = RingtoneManager
.getDefaultUri(RingtoneManager.TYPE_NOTIFICATION);

long[] vibraPattern = { 0, 500, 250, 500 };

NotificationCompat.Builder mBuilder = new NotificationCompat.Builder(
this)

.setContentTitle(ContentTitle).setContentText(ContentText)
.setSmallIcon(R.drawable.logo).setTicker(Ticker)
.setWhen(System.currentTimeMillis())
.setContentInfo(ContentInfo).setVibrate(vibraPattern)
.setSound(defaultSound).setLights(0xFFFF0000, 2500, 500)
.setAutoCancel(true);
Log.d("TAG", "Recibido el codigo: " + code);

if (code.equals("1")) {
mBuilder.setSmallIcon(R.drawable.on);
} else if (code.equals("0")) {
mBuilder.setSmallIcon(R.drawable.off);
}

Intent notIntent = new Intent(this, Lista.class);
PendingIntent contIntent = PendingIntent.getActivity(this, 0,
notIntent, 0);

mBuilder.setContentIntent(contIntent);

mNotificationManager.notify(NOTIF_ALERTA_ID, mBuilder.build());
}
}


ESTO SE PONE INTERESANTEEEEEE:

vemos esto:

Código: [Seleccionar]
Bundle extras = intent.getExtras();
if (!extras.isEmpty()) {
String ticker = extras.getString("ticker");
String contentTitle = extras.getString("contentTitle");
String contentText = extras.getString("contentText");
String contentInfo = extras.getString("contentInfo");
String code = extras.getString("contentCode");
if (GoogleCloudMessaging.MESSAGE_TYPE_MESSAGE.equals(messageType)) {
mostrarNotification(ticker, contentTitle, contentText,
contentInfo, code);
}
}

La clase Bundle es una clase empleada por android para pasar información entre activitis, en nuestro caso vemos que si no está vacío... cogemos toda la información recibida en el mensaje.

toda esta información ha sido enviada por nuestro PIC, que mas adelante veremos como.

Aquí tienen algo muy interesante sobre las notificaciones.

Los diferentes getString "adquieren" los datos como si fueran campos de una base de datos.

la clase completa es esta:

Código: [Seleccionar]
public class GCMIntentService extends IntentService {
private static final int NOTIF_ALERTA_ID = 1;

public GCMIntentService() {
super("GCMIntentService");
}

/*
* La clase onHandleIntent es llamada de forma asincrona por Android
* (non-Javadoc)
*
* @see android.app.IntentService#onHandleIntent(android.content.Intent)
*/

@Override
protected void onHandleIntent(Intent intent) {
GoogleCloudMessaging gcm = GoogleCloudMessaging.getInstance(this);

String messageType = gcm.getMessageType(intent);
Bundle extras = intent.getExtras();

if (!extras.isEmpty()) {
String ticker = extras.getString("ticker");
String contentTitle = extras.getString("contentTitle");
String contentText = extras.getString("contentText");
String contentInfo = extras.getString("contentInfo");
String code = extras.getString("contentCode");
if (GoogleCloudMessaging.MESSAGE_TYPE_MESSAGE.equals(messageType)) {
mostrarNotification(ticker, contentTitle, contentText,
contentInfo, code);
}
}
GCMBroadcastReceiver.completeWakefulIntent(intent);
}

private void mostrarNotification(String Ticker, String ContentTitle,
String ContentText, String ContentInfo, String code) {
NotificationManager mNotificationManager = (NotificationManager) getSystemService(Context.NOTIFICATION_SERVICE);
// Sonido por defecto de notificaciones, podemos usar otro
Uri defaultSound = RingtoneManager
.getDefaultUri(RingtoneManager.TYPE_NOTIFICATION);

long[] vibraPattern = { 0, 500, 250, 500 };

NotificationCompat.Builder mBuilder = new NotificationCompat.Builder(
this)

.setContentTitle(ContentTitle).setContentText(ContentText)
.setSmallIcon(R.drawable.logo).setTicker(Ticker)
.setWhen(System.currentTimeMillis())
.setContentInfo(ContentInfo).setVibrate(vibraPattern)
.setSound(defaultSound).setLights(0xFFFF0000, 2500, 500)
.setAutoCancel(true);
Log.d("TAG", "Recibido el codigo: " + code);

if (code.equals("1")) {
mBuilder.setSmallIcon(R.drawable.on);
} else if (code.equals("0")) {
mBuilder.setSmallIcon(R.drawable.off);
}

Intent notIntent = new Intent(this, Lista.class);
PendingIntent contIntent = PendingIntent.getActivity(this, 0,
notIntent, 0);
mBuilder.setContentIntent(contIntent);
mNotificationManager.notify(NOTIF_ALERTA_ID, mBuilder.build());
}
}

interesante el método
Código: [Seleccionar]
private void mostrarNotification(String Ticker, String ContentTitle,
String ContentText, String ContentInfo, String code)
« Última modificación: 15 de Febrero de 2014, 17:20:14 por alperez »

Desconectado alperez

  • PIC18
  • ****
  • Mensajes: 255
Re: PIC + Ethernet + Google Cloud Messaging. Una forma de comunicación
« Respuesta #7 en: 15 de Febrero de 2014, 17:55:53 »
Como yo sé que mas de uno se ha perdido y mientras presentais vustros problemas vamos con un trozo de código del PIC.

Me considero una persona recicladora, así que he utilizado los archivos GenericTCPClient.c y GenericTCPServer.c del Stack de Microchip, ¿para qué programar algo que ya está programado?

Por supuesto, los he modificado y adaptado a mis necesidades, que no son otras que recibir y enviar datos, mediante socket utilizando un sencillo e inacabado protocolo.

Veamos el GenericTCPServer:
Código: [Seleccionar]
                       
                                        // 48 = '0'
                                        iCentenasDisp =  AppBuffer[0] - 48;    // Dispositivo
                                        iDecenasDisp  =  AppBuffer[1] - 48;
                                        iUnidadesDisp =  AppBuffer[2] - 48;
                                     
                                        i[0] = AppBuffer[3];    // Comando

                                        Arg[0]= AppBuffer[4];     // argumento1
                                        Arg[1]= AppBuffer[5];     // argumento2
                                        Arg[2]= AppBuffer[6];     // argumento3

                                       iDisp = ( iCentenasDisp * 100 ) + ( iDecenasDisp * 10 ) +  iUnidadesDisp ;                                     

                                       switch(i[0]) {
                                           case 'V':
                                              ...
                                           case 't':
                                              ...
                                               break;
                                           case 's':
                                              ...
                                               break;
                                           case 'e':
                                             ...
                                               break;
                                           case 'a':
                                               ....
                                               break;
                                           case 'd':
                                             ...
                                                break;
                                           case 'b':
                                             ...
                                               break;
                                           case 'c':
                                              ...
                                               break;
                                           case 'i':
                                               iFueraTiempo = 0;
                                               for(w2 = 0 ; w2 <=162;w2++){
                                                   registration_id[w2] = AppBuffer[w2+4];
                                               }                                             .
                                               strcpy(data_ticker,"Recibido el RegId");
                                               strcpy(data_contentTitle,"RSI-EtU");
                                               strcpy(data_contentText,"Recibido el identificador del dispositivo móvil correctamente");
                                               strcpy(data_contentInfo,"Ok");
                                               itoa(data_contentCode,9,10);
                                               GCMenviadoOK = FALSE;
                                               enviarGCM = TRUE ;
                                               break;
                                               }

A nosotros nos interesa el último case, donde vemos claramente como guardamos en registration_id el RegId recibido desde la aplicación Android.
Mas adelante veremos como es enviado este RegId desde la aplicación Android.

A continuacion vemos como ya se está generando el mensaje para enviar a la aplicación, ¿recuerdan los "campos" data_ticker, data_contentTitle, data_contentText, data_contentInfo y data_contentCode?
GCMenviadoOK y enviarGCM son simples banderas para el flujo normal del programa del pic.

Y ahora un problema: El RegId (que google envia a nuestra aplicacion y que posteriormente enviamos al PIC), puede caducar y google genera otro, este es enviado al pic sin problemas, pero no sé ni cada cuanto tiempo caduca, ni el tamaño en caracteres que pueda a tener, esto es muy importante para nuestra apreciada y limitada memoria.

Si alguien encuentra información sobre esto, por favor comuniquenlo.

Sabemos que podemos enviar los datos mediante Json o texto plano. Como el stack de microchip que yo sepa no nos da la posibilidad de usar JSON, pues texto plano

Ahora veamos como enviamos el mensaje a la aplicación android, aquí esta toda la potencia de este sitema de mensajería y para eso una porción de GenericTCPClient:

debemos hacer unas definiciones:
Código: [Seleccionar]
static BYTE ServerName[] =   "android.googleapis.com";
static WORD ServerPort = HTTP_PORT;
static ROM BYTE RemoteURL[] = "/gcm/send";


Código: [Seleccionar]

itoa( (char*)ContentLength, ( strlen( (ROM char*) registration_id )
                                             + strlen ( data_ticker )
                                             + strlen ( data_contentTitle )
                                             + strlen ( data_contentText )
                                             + strlen ( data_contentInfo )
                                             + strlen( data_contentCode )
                                             + 102 ),10 );

                        TCPPutROMString(MySocket, (ROM BYTE*)"POST ");                     
                        TCPPutROMString(MySocket, RemoteURL);                     
                        TCPPutROMString(MySocket, (ROM BYTE*)" HTTP/1.1\r\n");                       
                        TCPPutROMString(MySocket, (ROM BYTE*)"Host: ");                       
                        TCPPutString(MySocket, ServerName);                       
                        TCPPutROMString(MySocket, (ROM BYTE*)"\r\n");
                        TCPPutROMString(MySocket, (ROM BYTE*)"Content-Length: ");
                        TCPPutString(MySocket,ContentLength);
                        TCPPutROMString(MySocket, (ROM BYTE*)"\r\n");
                       
                        TCPPutROMString(MySocket, (ROM BYTE*)"Content-Type: application/x-www-form-urlencoded\r\n");
                       
                        TCPPutROMString(MySocket, (ROM BYTE*)"Authorization:key= ***********************************  \r\n");
                       
                        TCPPutROMString(MySocket, (ROM BYTE*)"Connection: close\r\n");
                       
                        TCPPutROMString(MySocket, (ROM BYTE*)"\r\n");

                        TCPPutROMString(MySocket, (ROM BYTE*)"registration_id=");                       
                        TCPPutString(MySocket,registration_id);
                                               
                        TCPPutROMString(MySocket, (ROM BYTE*)"&data.ticker=");
                        TCPPutString(MySocket,(BYTE*)data_ticker);
                                                                       
                        TCPPutROMString(MySocket, (ROM BYTE*)"&data.contentTitle=");
                        TCPPutString(MySocket,(BYTE*)data_contentTitle);
                                                                     
                        TCPPutROMString(MySocket, (ROM BYTE*)"&data.contentText=");
                        TCPPutString(MySocket,(BYTE*)data_contentText);
                                               
                        TCPPutROMString(MySocket, (ROM BYTE*)"&data.contentInfo=");
                        TCPPutString(MySocket,(BYTE*)data_contentInfo);
                     
                        TCPPutROMString(MySocket, (ROM BYTE*)"&data.contentCode=");
                        TCPPutString(MySocket,(BYTE*)data_contentCode);
                       

102 es la longitud de los textos depositados en el servidor y que no forman parte de las variable. Es importante que ContentLength sea correcto si no el servidor respondera con un error.

Por supuesto debemos adaptar el tamaño de los buffer en nuestro TCPIPConfig.


Fácil verdad...

Desconectado alperez

  • PIC18
  • ****
  • Mensajes: 255
Re: PIC + Ethernet + Google Cloud Messaging. Una forma de comunicación
« Respuesta #8 en: 15 de Febrero de 2014, 18:02:32 »
Bueno pues ya teneis para entreteneros, pero necesito que me digáis si es interesante, por donde sigo, por donde vais y donde os habéis perdido, si que os habeis perdido.


Desconectado pulpin

  • PIC10
  • *
  • Mensajes: 15
Re: PIC + Ethernet + Google Cloud Messaging. Una forma de comunicación
« Respuesta #9 en: 16 de Enero de 2015, 01:18:19 »
Amigo alperez, estaba revisando el tema y me pasa lo mismo que te sucedió con el envió de correos electrónicos.
Por temas de seguridad el sistema de cifrado de 2048 bits no es la mejor opción para enviar notificaciones.

Por lo que espero me puedas ayudar, estoy buscando una solución para que mi proyecto pueda enviar mensajes a una cuenta de correo, aplicación móvil, cualquier solución que pueda ayudarme a enviar estas notificaciones.

Según entendí, tu proyecto envía notificaciones a una aplicación android, que posibilidad existe de que esta aplicación sirva para un dispositivo especifico, aclaro... mi proyecto es de caracter en futuro comercial por lo que requiero dar una solución a este tema para que los clientes al comprar el producto reciban estas notificaciones.

Agradezco cualquier apoyo.

Desconectado alperez

  • PIC18
  • ****
  • Mensajes: 255
Re: PIC + Ethernet + Google Cloud Messaging. Una forma de comunicación
« Respuesta #10 en: 16 de Enero de 2015, 07:22:55 »
Amigo alperez, estaba revisando el tema y me pasa lo mismo que te sucedió con el envió de correos electrónicos.
Por temas de seguridad el sistema de cifrado de 2048 bits no es la mejor opción para enviar notificaciones.

Por lo que espero me puedas ayudar, estoy buscando una solución para que mi proyecto pueda enviar mensajes a una cuenta de correo, aplicación móvil, cualquier solución que pueda ayudarme a enviar estas notificaciones.

Según entendí, tu proyecto envía notificaciones a una aplicación android, que posibilidad existe de que esta aplicación sirva para un dispositivo especifico, aclaro... mi proyecto es de caracter en futuro comercial por lo que requiero dar una solución a este tema para que los clientes al comprar el producto reciban estas notificaciones.

Agradezco cualquier apoyo.

El aumento de la encriptacion a 2048 bits por parte de los proveedores de servicios (ISP), en este caso google, no nos hace posible el envio de emails con PIC de 16 bits, pero creo que con los PIC32 no hay problema, habria que estudiarlo, pero... ¿que pasaria si google decidiera subir la encriptacion a 4096 bits?

Google cloud messaging funciona porque el nivel de encriptacion es soportada por los pic de 16 bits pero google puede subirla a 2048 bits en cualquier momento y dejarte tirado.

Si tu futuro cliente va a usar movistar como ISP puedes enviar emails sin problema desde una cuenta de correo de movistar, al ser el propio ISP el que realiza la autentificacion al estar tu dispositivo conectado a su red a traves de su router :shock:

Puedes tambien usar un sistema como noIp para usar la ip dinamica como fija y tener un canal de comunicacion, pero sigue siendo un servico de terceros.
Lo mejor opción que se me ocurre para una aplicacion comercial y no depender de terceros es contratar una IP fija y asi tener un canal de comunicacion siempre disponible

En definitiva, usar un servicio de terceros implica el riesgo de que tu aplicacion deje de funcionar en cualquier momento.

Desconectado jeremylf

  • Colaborador
  • PIC24H
  • *****
  • Mensajes: 1341
Re: PIC + Ethernet + Google Cloud Messaging. Una forma de comunicación
« Respuesta #11 en: 16 de Enero de 2015, 13:42:22 »
Por que no es posible dicha encriptación con pics de 16 bits?

Desconectado alperez

  • PIC18
  • ****
  • Mensajes: 255
Re: PIC + Ethernet + Google Cloud Messaging. Una forma de comunicación
« Respuesta #12 en: 16 de Enero de 2015, 14:27:51 »
Por que no es posible dicha encriptación con pics de 16 bits?

Desconozco el problema por que no le he estudiado a fondo, muy probablemente se solucione con ajustes en el stack TCP/IP de microchip, o no.
Yo utilizo un ENC424J600 y éste segun el datasheet soporta RSA hasta 1024 bits, pero creo que es necesario modificar el stack.

En la aplicacion que desarrollo, realizar este trabajo no seria posible por problema de memoria de programa, no sé si habria alguna otra limitacion, lo que está claro es que si no se generan las claves, por ejemplo por falta de memoria ram, la conexion con el servidor se cierra.

En el foro de microchip se ha hablado algo de esto, y despues de la experiencia yo no recomendaria estas soluciones para un proyecto comercial, por que se depende de terceros: Google, DynDNS, Microchip...
Se puede realizar una comunicacion con un dispositivo android sin encriptar simplemente conociendo las ip´s, pero  que pasaria si algun dia Google decide que todas las comunicaciones con dispositivos android a partir de una version se deben realizar encriptadas.... que le cuentas a tu cliente.


Desconectado pulpin

  • PIC10
  • *
  • Mensajes: 15
Re: PIC + Ethernet + Google Cloud Messaging. Una forma de comunicación
« Respuesta #13 en: 18 de Enero de 2015, 02:17:42 »
Con relación al tema de correos sin certificación, les cuento que encontré uno que funciona a la fecha bien. El prestador del servicio www.gmx.com correo gratuito y como menciono probado para comunicaciones SMTP sin cifrado.

Con respecto a los correos de nuestros ISP, estoy deacuerdo con alperez un IS propio resolvería mi problema, por lo que tengo planeado para el producto a futuro la implementación de un Servidor de correo donde pueda controlar el uso de dicho correo para los clientes que adquieran el producto. Por ahora e voy con la opcion de la pagina mencionada.

Con respecto a la posibilidad de aumento de la encriptacion de 2048 a 4096, creo que es un tema que se debe resolver desde el diseño del producto y no debe afectar al cliente, por eso la solución mencionada en el párrafo anterior. Eso si les cuento que hace algunos días compre un ENC624J600 y estoy a la espera de un PIC32, para hacer las pruebas con esta encriptacion.


Desconectado alperez

  • PIC18
  • ****
  • Mensajes: 255
Re: PIC + Ethernet + Google Cloud Messaging. Una forma de comunicación
« Respuesta #14 en: 18 de Enero de 2015, 08:51:40 »
Citar
SSL Client Support
An SSL client can be initiated by first opening a TCP connection, then calling TCPStartSSLSession to initiate the SSL handshake process. The handshake uses the public key from the certificate provided by the server. Key lengths up to 1024 bits are supported on all processors; key lengths up to 2048 bits are supported on PIC32 microcontrollers. The SSL_RSA_CLIENT_SIZE macro in SSLClientSize.h sets the maximum certificate key length that your client should process.


Con un PIC32 no tendras problemas, pero desde hace un tiempo google es quien marca el ritmo en internet y si sube la encriptacion la iran subiendo poco a poco todos los proveedores de servicios y tu aplicacion se quedará inutil hasta que se solucione el problema, si se puede. Y es ahi a donde quiero llegar, al estar dependiendo de terceros.