Re: Http server implementation for Windows Media Server

Thanks.,
Actually I used the send_packet feature of WinPcap but I think that a
similar problem applies to me as would happen with raw sockets. Now I think
that this feature is not relevant to tcp but only to udp or similar
protocols.

Regards

Gur
"Alexander Nickolov" <agnickolov@xxxxxxxx> wrote in message
news:#F6nGjG2HHA.5740@xxxxxxxxxxxxxxxxxxxxxxx
You'd be much better off recording the TCP-level data instead
of the raw packets. I'm assuming you are using a raw TCP
socket. Dump that idea and use a regular TCP socket instead.

To answer your question, the packets aren't ACKed because
they are all discarded as lying outside the TCP window for the
current TCP connection (due to your sequence number mismatch).

--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD
email: agnickolov@xxxxxxxx
MVP VC FAQ: http://vcfaq.mvps.org
=====================================

"Gur" <gur@xxxxxxxxx> wrote in message
news:%23xmNAkB2HHA.5360@xxxxxxxxxxxxxxxxxxxxxxx
In the previous post I forgot to indicate a very important fact - that
is,
the client (which is a Windows Media Player) doesn't ACKs the above
packets
which it should, since my Http server simulates for him a Windows Media
Server and sends the original packets with the slight modification of a
modified port.

Regards

Gur

"Gur" <gur@xxxxxxxxx> wrote in message
news:e3l18aA2HHA.1208@xxxxxxxxxxxxxxxxxxxxxxx
I do it inside the Http server code. As described in the first post,
the
Http server reads packets one by one from the dump, sending them to
the
client after modifying tcp parameters like addresses, ports etc. In
this
case everything left unchanged but the port, and the "relative sequence
number" jumps to a huge value.
Regards

Gur

"Arkady Frenkel" <arkadyf@xxxxxxxxxxxxxxxx> wrote in message
news:eNrISB$1HHA.4880@xxxxxxxxxxxxxxxxxxxxxxx
Where do you do(modify) it ?
Arkady

"Ronny" <ronny@xxxxxxxxxxx> wrote in message
news:uR9ltw%231HHA.5772@xxxxxxxxxxxxxxxxxxxxxxx
Thanks,
I think I understand a bit more following your direction...
Now to a real case that I encounter, as described in the first post
of
this
thread, modifying in the tcp packet before transmitting, just the
port
of
the client as the port is usually different than the original one,
causes
a
real time sniffer to indicate a huge "relative sequence number".
Leaving
it
without modification causes an indication of 1 - just as it was in
the
original packet. Why should the port value influence on that?
Can you explain that?

Regards

Gur
"Arkady Frenkel" <arkadyf@xxxxxxxxxxxxxxxx> wrote in message
news:OSB8$$y1HHA.5884@xxxxxxxxxxxxxxxxxxxxxxx
On the tcp layer, both server's and client's tcpip stack do that
Arkady
"Gur" <gur@xxxxxxxxx> wrote in message
news:eGqSoat1HHA.484@xxxxxxxxxxxxxxxxxxxxxxx
Thanks,
Suppose a common scenario where a standard Web Server responds
to
a
GET
Http request. Does the server ever ACKs the client and when?

Thanks

Gur
"Arkady Frenkel" <arkadyf@xxxxxxxxxxxxxxxx> wrote in message
news:uystfhs1HHA.1204@xxxxxxxxxxxxxxxxxxxxxxx
That strange that no ACK appear because any data should be
ACKed
Arkady

"Gur" <gur@xxxxxxxxx> wrote in message
news:ukd9yIq1HHA.1336@xxxxxxxxxxxxxxxxxxxxxxx
Hi all,

I'm trying to implement a specific Http server that listens on
port
8080
(not the standard 80). Actually it resembles a Windows Media
Server
that
also works as a HTTP server (among some other modes).
I have a dump file of prercorded transmision from an actual
Window
Media
Server and Windows Media Player, and my server implementation
should
transmit them after establishing the tcp connection with the
Player.
In reality, the connection is established but the server
behaves
with
the following anomalies-
1. After the "GET" transaction by the Player, the server
transmits
an
ACK which doen't appear in the normal case.
2. The first dump packet that is being transmitted starts
with
a
huge
"Realtive Sequence Number" instead of a 1.

Can someone advise please?

Regards

Gur



















.

Relevant Pages

  • Re: Problem with writing fast UDP server
    ... UDP packets per second. ... socket and threads. ... I wrote a simple case test: client and server. ... The maximum theoretical limit is 14,880 frames per ...
    (comp.lang.python)
  • Re: network programming: how does s.accept() work?
    ... The articles and books I've read all claim that the server ... port 5053 is a 'listening' port only. ... the server creates a new socket for communication between the client ... on the network, and in the RFCs which define the TCP protocol (UDP too, but ...
    (comp.lang.python)
  • Re: Detecting when a socket has been closed.
    ... shutdown the server closing the socket the client still thinks the socket is open. ... First send will not throw exception, because there is no way for TCP stack to know that other end has actually closed its receiving side. ... It takes some time for packet to reach other side and return information that server side is gone. ... in case other end has closed socket and network is still operating after first send TCP RST segment will be returned to TCP stack notifying it connection has gone down. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Socket switch delay
    ... The server uses blocking sockets just because I am also using Overlapped IO ... structures to send the packets. ... The reason I am using a 0 bytes send buffer in my socket (i.e. ...
    (microsoft.public.win32.programmer.networks)
  • Re: Socket switch delay
    ... > I was referring to the client sending data on this socket while the server ... sockets to provide TCP support without also supporting asynchronous ... > The server uses blocking sockets just because I am also using Overlapped ... > structures to send the packets. ...
    (microsoft.public.win32.programmer.networks)
Loading