[VB.NET 2005] UDP ou TCP/IP ???? ou os dois ??

[watt]

Oi pessoal!

há coisa de uns meses acordei e pensei em criar um jogo on-line de futebol, e comecei... criei a bd em mysql, o motor do jogo e o cliente ... mais tarde tive problemas com a velocidade das consultas á BD, então resolvi alterar o meu jogo. Implementei a transferencia de dados por UDP e agora estou a ter outro problema, que é quando o servidor envia dados para o cliente nem sempre chegam, mas do cliente para o server nunca falhaou.

Eu sei que o protocolo udp é o mais rapido, mas não se sertifica se o cliente recebe os dados, calculo que seja isso que me está a acontecer.

que é que voces recomendão ??

já pensei em por o cliente a enviar dados para o servidor em udp

e o servidor para o cliente em tcp/ip.

[NuGuN]

Eu se fosse a ti utulizava a TCP para os 2!

Cumps

[Hipnoted]

Eu não percebo nada de VB .NET, mas o mesmo já não se passa com UDP e TCP.

Se fosse a ti escolhia apenas um dos dois para tudo. Ou seja não usava TCP para um e UDP para outro.

Eu escolheria TCP, apesar de se rmais lento é mais fiável. 😄

[watt]

tão acho que me vou dedicar ao tcp. Mas quando se fala de de ser mais lento,é micro segundos "a olho nu" não se nota... ou nota-se ?

alguem daki tem manuais de tcp/ip para vb.net? é que a ultima vez que tentei usar isso deu buraco, só conseguia uma ligação de cada vez ao servidor, e não consegui por os dois a enviar e receber dados ao mesmo tempo.

[Hipnoted]

tão acho que me vou dedicar ao tcp. Mas quando se fala de de ser mais lento,é micro segundos "a olho nu" não se nota... ou nota-se ?

alguem daki tem manuais de tcp/ip para vb.net? é que a ultima vez que tentei usar isso deu buraco, só conseguia uma ligação de cada vez ao servidor, e não consegui por os dois a enviar e receber dados ao mesmo tempo.

Não se nota muito. Aliás não se nota em transferências pequenas...

[watt]

tão para aquilo que eu quero deve dar.

o que o meu programa faz é enviar comandos sql e receber as respostas... e num futuro é cordenadas de alguns objectos

[TheDark]

O UDP é para ser utilizado em ligações que não sofram muito com pequenas falhas. O que não é o teu caso.

Já o TCP é para ser utilizado em ligações em que é crítico que toda a informação enviada chegue ao seu destino, o que é o teu caso 😄

[shumy]

Decide-te, vas usar um servidor SQL ou vas usar TCP com um protocolo inventado por ti?

É que vas acabar sempre por usar TCP já que as comunicações SQL são TCP.

Normalmente não se utiliza BD's sql como repositórios de dados para jogos em tempo real on-line.

Mas se é só umas coordenadazitas, não é isso que vai atrasar.

Só vejo uma situação muito especifica (que pode ser a tua) em que o uso de UDP podia ser o melhor. Dentro de uma intranet com o servidor a fazer multicast para os seus clientes, mas claro, com um processo que controla as chegadas das mensagens, evitando perda destas.

[HecKel]

Bem, li isto na diagonal e tenho ideia que já referiram isto aqui, mas resumidamente:

UDP - NÃO te garante que os pacotes chegam ao destino, tu nunca sabes esta informação. Se algum pacote se perder tu não vais saber qual foi para o reenviar (logo, para o teu problema NÃO SERVE)

TCP - Fiabilidade! A cada pacote recebido é retransmitido um acknoledgement (confirmação) para o emissor de forma a indicar que o pacote foi recebido correctamente. Se o pacote se perder, ou o acknoledgement o emissor envia novamente o pacote que poderá ser sobreposto. Ou seja, acabas por receber sempre tudo e o emissor SABE que foi recebido com sucesso! (é isto que queres)

Basicamente..., é isto 😉

abraços, HecKel

[watt]

já estou a trabalhar no tcp ip, ainda estou no inicio... já tenho varios clientes a ligarem-se ao servidor, só que no que diz respeito há escrita, isto corre mal.

A minha aplicação começa a usar cada vez mais memoria até q fica tudo encravado, qd meto 2 clientes a escrever.

a idei era receber a informação que cada um dos clientes envia, e o ip do mesmo. para depois responder para o local correcto.

o codigo que tenho é o seguinte.

Public Shared iplist As Hashtable

Sub servir()

        cont = 0

        iplist = New Hashtable

        listen.Start()

        While serv = "sim"

            If listen.Pending = True Then

                cont = cont + 1

                tcpcliente = listen.AcceptTcpClient

                stream = tcpcliente.GetStream()

                'MsgBox(tcpcliente.Client.RemoteEndPoint.ToString)

                iplist.Add(cont, tcpcliente.Client.RemoteEndPoint.ToString)

                Invoke(New importtxt(AddressOf enviartxt), cont)

            End If

            If cont > 0 Then

                recebe = "sim"

                startleitura()

            End If

        End While

    End Sub

    Sub receber()

        While recebe = "sim"

            Dim bytes(tcpcliente.ReceiveBufferSize) As Byte

            stream.Read(bytes, 0, bytes.Length)

            dados = Encoding.UTF8.GetString(bytes)

            If dados <> "" Then Invoke(New importtxt2(AddressOf escreverform), dados)

        End While

    End Sub

os sub servir e receber estão a correr dentro de thread's

Se conseguir por isto a dar acredito que daki a uns dias esteja a por o meu jogo na secção dos projectos pessoais... embora esteja lá um do mesmo estilo... mas existem diferenças.

[TheDark]

Não vi o código muito aprofundadamente, mas há ali uma coisa... estás a fazer

While recebe = "sim"

mas não te vejo a alterar a variável recebe, logo isso fica a receber para sempre? Ou estás a alterá-la noutro sítio? Assim é fácil bloquear o programa.

[watt]

tenho um botão que liga mete a variavel a "sim" e "não", mas para estar a ver se os clientes me enviam informação não tenho q ter um ciclo a verificar.

[Crack]

Não vi o código muito aprofundadamente, mas há ali uma coisa... estás a fazer

While recebe = "sim"

mas não te vejo a alterar a variável recebe, logo isso fica a receber para sempre? Ou estás a alterá-la noutro sítio? Assim é fácil bloquear o programa.

Aquilo ali são thread o programa nunca fica bloquiado com ciclos infinitos

Dim hash as New hastable

Dim ThrReceive As New Thread(AddressOf Receive)

    Private Sub Receive()

        While (1)

            Dim x As DictionaryEntry

            For Each x In hash

                tcpClient = x.Value

                Try

                    networkStream = tcpClient.GetStream()

                    If networkStream.DataAvailable And networkStream.CanRead Then

                        While (tcpClient.Available > 0)

                            bCount = networkStream.Read(bytes, 0, tcpClient.Available)

                            ClientData = Encoding.ASCII.GetString(bytes, 0, bCount)

                        End While

                        Message.Invoke(Nothing)

                    End If

                Catch ex As Exception

                    TcpHash.Remove(x.Key)

                    Exit For

                End Try

            Next

            If tcpListener.Pending Then

                Dim newClient As TcpClient

                newClient = tcpListener.AcceptTcpClient

                Dim GuidID As Guid = Guid.NewGuid

                TcpHash.Add(GuidID.ToString, newClient)

            End If

            ThrReceive.Sleep(100)

        End While

    End Sub

Basicamente o que isto faz:

no If tcpListener.Pending guarda todos os utilizadores que entrarem num hastable

no For, tenta (no Try) ver se algum utilizador enviou dados

[TheDark]

Aquilo ali são thread o programa nunca fica bloquiado com ciclos infinitos

Se nunca saíres dos ciclos, e por cada utilizador criares uma thread que fica presa no ciclo, eventualmente tens uma data de ciclos a correr simultaneamente (salvo seja). Ou seja, o ciclo principal do programa realmente não bloqueia, mas os threads bloqueiam. Pelos sintomas que ele descreve, lembrei-me imediatamente disso.

Mas como os meus conhecimentos de Basic são básicos... pode estar-me a escapar qualquer coisa.

[Crack]

só é perciso uma thread, e o Sleep(100) faz com que o programa nao fique "saturado"

[TheDark]

Mas se só precisas de uma thread, porque é que estás a criar uma nova?

[Crack]

secalhar não me expliquei bem

se ele tiver um botão para fazer Connect, ele vai dizer ThrReceive.Start e a thread inicia apartir dai depois de iniciada ela fica em ciclo, a thread é so uma e ela nunca chega acabar, e não pode acabar porque ta constantemente a verificar se a utilizador para entrar ou para receber dados...so acaba se ele depois num botão de Disconnect fizer ThrReceive.Abort.

[watt]

alguem me sabe dizer porquê é que estou sempre a perder dados na stream ??

é que estou a ter montes de problemas na comunicação, entre servidor e cliente.